On Tue, 4 Apr 2023 08:45:54 +0200 Jinpu Wang <jinpu.w...@ionos.com> wrote:
> Hi Yu, > > On Mon, Apr 3, 2023 at 6:59 PM Yu Zhang <yu.zh...@ionos.com> wrote: > > > > Dear Laurent, > > > > Thank you for your quick reply. We used qemu-7.1, but it is reproducible > > with qemu from v6.2 to the recent v8.0 release candidates. > > I found that it's introduced by the commit 9323f892b39 (between v6.2.0-rc2 > > and v6.2.0-rc3). > > > > If it doesn't break anything else, it suffices to remove the line below > > from acpi_pcihp_device_unplug_request_cb(): > > > > pdev->qdev.pending_deleted_event = true; > > > > but you may have a reason to keep it. First of all, I'll open a bug in the > > bug tracker and let you know. > > > > Best regards, > > Yu Zhang > This patch from Igor Mammedov seems relevant, > https://lore.kernel.org/qemu-devel/20230403131833-mutt-send-email-...@kernel.org/T/#t this patch targets corner case of early boot where guest hasn't initialized ACPI subsystem yet and 'broken' management asking to unplug device too early which leads to device stuck in being unplugged state due to regression in QEMU. However, It doesn't apply to fully booted guest. [...] > >> > The purpose is for detecting the end of the PCI device hot-unplug. > >> > However, we feel the > >> > error confusing. How is it possible that a disk "is already in the > >> > process of unplug" > >> > during the first hot-unplug attempt? So far as I know, the issue was > >> > also encountered by > >> > libvirt, but they simply ignored it: > >> > > >> > https://bugzilla.redhat.com/show_bug.cgi?id=1878659 > >> > <https://bugzilla.redhat.com/show_bug.cgi?id=1878659> see my other reply email/BZ comment 17. [...]
