Re: [libvirt] VFIO device groups and libvirt
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?