Hi,
> > So, in case the first time didn't work (for example due to the guest not
> > listening because grub just doesn't do that), you can try a second time
> > once the linux kernel is up'n'running.
> >
> > I suspect this patch will break that (didn't actually test though).
>
> I think the solution to this problem is to not check for
> pending_deleted_event value in qmp_device_del().
>
> But this has been explicitly added by:
>
> commit cce8944cc9efab47d4bf29cfffb3470371c3541b
> Author: Julia Suvorova <jusual@redhat.com>
> Date: Thu Feb 20 17:55:56 2020 +0100
>
> qdev-monitor: Forbid repeated device_del
>
> [ ... ]
>
> So do you mean ACPI differs from PCIe Native hotplug in this case?
Yes.
It's one of the issues I'm trying to address with the
https://gitlab.com/kraxel/qemu/-/commits/sirius/pcie-hotplug
series. See this commit:
https://gitlab.com/kraxel/qemu/-/commit/675d9257d794c9d59ea7c80f48fe176a2aa3f8ba
I think the scope of this patch is limited to making the acpi hotplug path identical to PCIE native path wrt failover. If there are issues with the existing approach, it should be looked into separately using subsequent patches.
So, yes, I think acpi and pcie hotplug should show consistent behavior
here. And I think we need some way to recover in case the guest didn't
respond to an unplug event. Just allowing to send device_del multiple
times looks like a sensible approach to me, and given OpenStack already
does that it looks like the most sensible way forward.
take care,
Gerd