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

[Alex Williamson]

On Tue, 17 Dec 2019 13:43:14 -0300
Daniel Henrique Barboza <danielhb413 at gmail.com> wrote:

> On 12/17/19 1:32 PM, Alex Williamson wrote:
> > On Tue, 17 Dec 2019 11:25:38 -0500
> > Laine Stump <laine at laine.org> 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.

There are of course existing, working managed=yes configurations where
the set of assigned devices is only a subset of the IOMMU group, and
the user has configured other means to make the group viable relative
to vfio.  The statement above doesn't convince me that the next
iteration isn't simply going to restrict its manipulation of other
devices.  As Laine says above and I said in my previous reply, libvirt
should not manipulate the driver binding of any devices not explicitly
listed in the domain XMl.  Thanks,

Alex