Re: [PATCH 0/8] Force detach PCI devices for ACPI-based and PCIe native hot-unplug

[Igor Mammedov <imammedo@xxxxxxxxxx>]

On Wed, 26 Aug 2026 09:15:47 -0700
Dongli Zhang <dongli.zhang@xxxxxxxxxx> wrote:

> On Mon, Aug 24, 2026 7:44:49AM -0700, Daniel P. Berrangé wrote:
> > On Sun, Aug 23, 2026 at 06:13:30PM -0700, Dongli Zhang wrote:  
> >> Hot-unplugging a PCI device can require cooperation from the guest. For
> >> ACPI PCI hotplug, QEMU notifies the guest through ACPI and the guest
> >> eventually writes the ACPI PCI eject register. For PCIe native hotplug,
> >> QEMU notifies the guest through the PCIe hotplug mechanism and waits for
> >> the slot unplug flow to complete. Only after that completion does QEMU
> >> unrealize the device and emit DEVICE_DELETED.
> >> 
> >> This can leave a device stuck in the unplug pending state when the guest
> >> does not cooperate. Examples include:
> >> 
> >> 1. The guest has panicked, or the relevant ACPI/PCI hotplug driver is
> >> unavailable.
> >> 
> >> 2. The guest is stalled and cannot handle the hot-unplug event. For
> >> example, stalling the Linux [irq/9-acpi] kernel thread can reproduce this
> >> for ACPI-based hot-unplug.
> >> 
> >> 3. The device was attached to a slot that the guest cannot use. For
> >> example, a pcie-root-port only supports slot 0. If a device is added to a
> >> non-zero slot below a pcie-root-port, the guest may never discover the
> >> device and therefore may never complete the unplug request.

all of above is actually expected, no (functioning) driver => no hotplug/unplug.
it's the guest problem. Once device it exposed to guest its life-cycle
not longer owned by QEMU.

That's what one would see in real hw as well, you press eject button
but it will not do anything if OS doesn't process it.
also see comment at the end.

> >> 
> >> The non-zero slot case has also been discussed in:
> >> 
> >> hw/pci: warn when PCIe device is plugged into non-zero slot of downstream 
> >> port
> >> https://gitlab.com/qemu-project/qemu/-/commit/  
> > ca92eb5defcf9d1c2106341744a73a03cf26e824  
> >> 
> >> hw/pci: add comment to explain checking for available function 0 in pci 
> >> hotplug
> >> https://gitlab.com/qemu-project/qemu/-/  
> > commit/67d045a0ef5b9c5f871c3a1d87325a8a42d2b9d5  
> >> 
> >> pci: don't skip function 0 occupancy verification for devfn auto assign
> >> https://gitlab.com/qemu-project/qemu/-/commit/  
> > e228d62b4af29bca698ec57efdceb46f392f5444  
> >> 
> >> For example, if root-port.1 is a pcie-root-port, the following command adds
> >> a vhost-scsi-pci device to an invalid slot:
> >> 
> >> (qemu) device_add 
> >> vhost-scsi-pci,id=scsi01,wwpn=naa.5001405324af0985,bus=root-port.1,addr=01.0
> >> warning: PCI: slot 1 is not valid for vhost-scsi-pci, parent device only 
> >> allows plugging into slot 0.  
> > 
> > This rather looks like it should be a fatal error, not a mere warning.
> > 
> > If I follow the commit ca92eb5def it links to 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2128929
> > which states that this configuration is going to lead to a crash in
> > QEMU on guest OS shutdown. IMHO that crash is sufficient to justify
> > making this a fatal error.
> > 
> > If we actually wanted this to remain a warning, then that shutdown
> > crash would need to be fixed.
> >   
> 
> Thank you very much!
> 
> I see that the issue has been fixed. The ticket mentions the following.
> 
> "What I am observing is that it seems when the slot ID != 0, the guest OS 
> seems
> to ignore this and we never seem to hit ich9_pm_device_unplug_cb()."
> 
> Based on my experience and evaluation, ACPI-based hotplug is more likely to
> encounter an issue where the guest VM does not respond to an unplug operation.

I'm not sure it's a good idea to delete device when guest still thinks it's 
there
(you can make guesses on QEMU side if it's in use, how useful those are is 
questionable).

as far as I know, ACPI hotplug has no notion of surprise removal (pls educate 
me if it's not the case),
so I wouldn't do what you are proposing here at all, it's basically asking for 
disaster to happen.
And all this is basically for dealing with abused qemu flexibility.

Please (re)formulate usecase and make it more clear as what is eludes me
no matter how many times i've read this cover letter.

On positive note:

What you can try to implement is native PCI-E support for surprise removal.
How hard that would be I don't know. And I would well expect if one deviates 
from
real hw expectations/configs (such as not 0 slot/partial func removal),
one would quickly stumble upon issues as  that's not what what vendors 
write/test
drivers for.

Even if it's not likely to be used in practice (guest still might not support 
it),
it may serve as test-bed for guest drivers.

> Thank you very much!
> 
> Dongli Zhang
>