On 12/17/19 1:43 PM, Daniel Henrique Barboza wrote:
I don't actually recall saying that :-). I haven't looked in the list
archives, but what I *can* imagine myself saying is that only devices
mentioned in the XML should be manipulated in any way by libvirt. So,
+1
for example, you shouldn't unbind device X from its host driver if there
is nothing in the XML telling you to do that. But if a device isn't
mentioned in the XML, and is already bound to some driver that is
acceptable to the VFIO subsystem (e.g. vfio-pci, pci-stub or no driver
at all (? is that right Alex?)) then that should not create any problem.
Yes, that's right.
Doing otherwise would break too many existing configs. (For example, my
own assigned-GPU config, which assumes that all the devices are already
bound to the proper driver, and uses "managed='no'")
I am re-reading this info and reassessing what I intended to do. Suppose a
scenario in which host IOMMU has PCI devices A,B and C. Let's also suppose
that all of them are already bind to vfio-pci.
If I create a guest with A and B as PCI hostdevs, with managed=yes, using
vfio-pci, the setup would work as it is. If I put the IOMMU validation I was
planning to, it will stop working because "C" isn't described in the domain
XML.
If we stick with the directive "Libvirt shouldn't tamper with devices that
are not described in the domain XML" that Laine mentioned up there, and this
directive alone, then I can't make such assumptions about whether the user
will be OK with assigning everything to vfio-pci, given that there are other
acceptable alternatives for the VFIO subsystem that aren't restricted to
that.
I'm convinced that this validation I was pursuing here is a bad idea. It
has a great potential of being annoying, making assumptions about real life
configurations that aren't true, and offering not much in return. I'll
remove it from the series. The result is that the user will have a
new option to let Libvirt control all the IOMMU devices, making some
of the unassignable to the guest. But it will be a new option, not a
new rule that all existing domains will need to adhere to.
Thanks,
DHB
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
