[PATCH v1 10/12] add hostdev handling for bhyve

Ryan Moeller ryan at ixsystems.com
Mon Feb 24 18:47:52 UTC 2020


> Can you split this patch up into a few pieces.
>
> We generally want the changes to the XML parser/formatter to
> be separate from any driver code, as the first part.
>
> Then I'd suggest a separate patch for the PCI and the SCSI
> hostdev support in bhyve.

> For the conf stuff we'll need a docs update in docs/formatdomain.html.in
> at the same time as this parser additions.

> If you can provide a little detail in the commit message on why the current
> SCSI hostdev stuff doesn't work for FreeBSD that'd be useful too.

Can do.

> I didn't see anything in the code is keeping track of in-use PCI devices.
> Does something else in FreeBSD guarantee that you won't have bad stuff
> happening if the PCI device is attempted to be assigned to 2 guests ?
>
> Also is it required to manually detach the host OS driver first, or
> is that automatic ?  This ties into which 'managed=no|yes' attribute
> choices you should permit for the hostdev.

There is not automatic management for passing through devices. It is
configured by a list of PCI devices that are to be reserved for
passthrough at boot. The vmm module will attach the listed devices to
the ppt driver before something else can try to take them.

If the same device is assigned to multiple VMs then the bhyve command
will error with an appropriate message when trying to start VMs after
the first one takes the device. This seems fine to me. I have several
VMs configured to use the same devices but only can run one at a time.
This is for testing drivers in different stable branches, on different
operating systems, etc.

I could imagine some future extension of this work to enable libvirt
to automatically configure devices for passthrough at next boot
perhaps, but that is more of a convenience than a necessity. Right now
passthrough can only be configured by manually putting the bhyve
command line args in the config, so this change is already a definite
improvement in terms of leveraging libvirt's facilities.

-- 
Ryan Moeller
iXsystems, Inc.
OS Developer
Email: ryan at iXsystems.com





More information about the libvir-list mailing list