[libvirt] RFC: revival of hotplug/unplug for PCI Multifunction devices in QEMU guests

[Daniel P. Berrangé]

On Thu, Aug 22, 2019 at 05:09:10PM -0300, Daniel Henrique Barboza wrote:
> Hi Daniel,
> 
> On 6/19/19 4:31 AM, Daniel P. Berrangé wrote:
> > On Tue, Jun 18, 2019 at 03:04:40PM -0300, Daniel Henrique Barboza wrote:
> > > Hi,
> > > 
> > > This is labeled as RFC but it's more like a FYI to let people know and
> > > comment beforehand. Shiva sent a 28 patch series last year that implements
> > > hotplug/unplug support for PCI multifunction devices [1]. The design
> > > motivation of his work was based in a RFC sent to this mailing list back
> > > in 2016 [2].
> > > 
> > > I'll briefly summarize the goals and motivations here. What we have today
> > > in Libvirt:
> > > 
> > > - no hotplug/unplug support for multifunction PCI devices
> > > 
> > > This is explained in details in [2]. When hotplugging a multifunction
> > > device, QEMU will queue the hotplug operation of all non-zero functions and,
> > > when function 0 is hotplugged, all functions are hotplugged together. This
> > > is true for all archs that supports PCI multifunction devices in QEMU. For
> > > unplug it varies: x86 will unplug all functions if any function is
> > > unplugged, ppc64 needs to unplug each one.
> > Do you know anything about why ppc64 & x86 are different in this respect
> > in QEMU.  I think it would be desirable to fix QEMU so that unplug works
> > consistently across architectures. These kind of behavioural differences
> > are a cause of pain as x86 gets all the day to day testing & leaving
> > ppc64 to bitrot if it behaves differently.
> 
> Finally had the time to look into it in QEMU. The reason for the difference
> is indeed architectural - x86 handles it in slot-granularity level and PPC64
> handles it in function level. This is why in x86 unplugging any function
> will
> remove the whole slot, while in PPC64 each non-zero function needs
> to be detached first.
> 
> I've sent a patch to QEMU to change the way PPC64 behaves in function
> zero unplug [1]. Instead of bail out claiming that there are non-zero
> functions left, QEMU will simply remove the remaining functions by itself.
> This behavior happens only with function zero unplug (at least in this first
> implementation). Not sure if QEMU will accept it, but if it does, it'll
> spare us some patches in Libvirt unplug code for PCI Multifunction.
> Let's see how it goes.

Looks like the ppc maintainer has queued the patch, which is good.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|