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