On 8/23/19 7:28 AM, Daniel P. Berrangé wrote:
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:
>> [...]
> 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.
Yes, that will reduce the amount of patches needed for the hot
unplug code for both archs (since x86 was being impacted by
how ppc64 does the unplug as well). I'll work in resubmit the
patch series considering the upstream PPC64 change.
Thanks,
DHB
Regards,
Daniel