[libvirt] VFIO device groups and libvirt

[Laine Stump]

On 05/30/2013 01:18 PM, Alex Williamson wrote:
> nit, vfio is not a stub driver, it's an actual driver. vfio also
> whitelists some host drivers. The two so far are pci-stub and
> pcieport. libvirt should not disconnect root ports from pcieport
> unless the root port is being assigned to a guest (which isn't supported).


So are you saying that if someone wants to assign a device that's in the
same group as a device that is already bound to pcieport, even if they
say its okay to bind the entire group to vfio-pci, we should just leave
the pcieport device alone? Is the same true for pci-stub?


> pci-stub can be used to satisfy the requirement that the device is
> disconnected from the host, but doesn't allow direct access of the
> device through vfio.
>
> I'm also working on a kernel patch that will allow a user to specify on
> the kernel command line devices and sets of devices to assume have ACS
> support.  This should allow users to strategically change device
> grouping if they want to opt-in to the risk of assigning devices in
> topologies without ACS support.



If that's possible, then it seems the usefulness of what I'm doing
becomes significantly less (or at least the need for it becomes much
less urgent).



> The additional xml flag is unfortunate, but I can see why you want it.


I dislike it too, since it means that we will never be able to support a
simple <hostdev> assignment of a device that's in a group without
specifying a <driver group='allow'/>.

I'm almost inclined to just categorically state that if you want to use
VFIO to assign a device that's in a group, you can't use <hostdev
managed='yes'>, but instead have to manually detach the devices in the
group from the host and attach them to vfio-pci/pci-stub (libvirt
provides an API to do this - virNodeDeviceDetachFlags()). This would
keep the XML clean for the cases of non-grouped devices (as well as
devices in a group of devices that were all bound to vfio-pci, pci-stub,
or pcieport); for for devices in groups that used other drivers, the
user could either add the kernel commandline options you mentioned (to
allow willy-nilly assignment to any combination of guests) or bind the
devices in the group to vfio-pci prior to starting the guest / assigning
the device.

Does that sound like a reasonable level of usability?