Re: [libvirt] [PATCH v4 0/5] PCI hostdev partial assignment support

On 12/17/19 1:32 PM, Alex Williamson wrote: > On Tue, 17 Dec 2019 11:25:38 -0500 > Laine Stump <laine(a)laine.org&gt; wrote: > >> On 12/16/19 6:03 PM, Daniel Henrique Barboza wrote: >>> About breaking existing configurations, there is the possibility of not >>> going forward with patch 03, which is enforcing this rule of declaring >>> all the >>> IOMMU group. Existing domains will keep working as usual, the option to >>> unassign devices will still be present, but the user will have to deal >>> with >>> the potential QEMU errors if not all PCI devices were detached from >>> the host. >>> >>> In this case, the 'unassigned' type will become more of a ON/OFF >>> switch to >>> add/remove the PCI hostdev from the guest without removing it from the >>> domain XML. It is still useful, but we lose the idea of all the IOMMU >>> devices being described in the domain XML, which is something Laine >>> mentioned it would be desirable in one of the RFCs. >> >> >> 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'") This is the new approach of the series I implemented today and plan to to send for review today/tomorrow. I realized, after all the discussions yesterday with Alex, that the patch series would be best just sticking with what we want fixed (managed=yes and parcial assignment) and leaving unmanaged (managed=no) configurations alone. If the user has an existing, working unmanaged setup, this means that the user chose to manage device detach/re-attach manually and shouldn't be bothered with a change that's aimed to managed devices.