[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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:

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.

[1] https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg04820.html




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]