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?