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? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list