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

[Igor Mammedov <imammedo@xxxxxxxxxx>]

On Thu, 3 Sep 2026 16:17:20 -0400
"Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote:

> On Thu, Sep 03, 2026 at 05:28:35PM +0200, Igor Mammedov wrote:
> > 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),  
> 
> why would it not?
> 
> how do you think you can pull a laptop out of a dock?
> I expect bus check + _STA and config space saying it is gone
> will do exactly that.
> 
> 
> Here's linux code:
> static void acpiphp_check_bridge(struct acpiphp_bridge *bridge)
> {       
>         struct acpiphp_slot *slot;
> 
>         /* Bail out if the bridge is going away. */
>         if (bridge->is_going_away)
>                 return;
> 
>         if (bridge->pci_dev)
>                 pm_runtime_get_sync(&bridge->pci_dev->dev);
>         
>         list_for_each_entry(slot, &bridge->slots, node) {
>                 struct pci_bus *bus = slot->bus;
>                 struct pci_dev *dev, *tmp;
> 
>                 if (slot_no_hotplug(slot)) {
>                         ; /* do nothing */
>                 } else if (device_status_valid(get_slot_status(slot))) {
>                         /* remove stale devices if any */
>                         list_for_each_entry_safe_reverse(dev, tmp,
>                                                          &bus->devices, 
> bus_list)
>                                 if (PCI_SLOT(dev->devfn) == slot->device)
>                                         trim_stale_devices(dev);
> 
>                         /* configure all functions */
>                         enable_slot(slot, true);
>                 } else {
>                         disable_slot(slot);
>                 }
>         }
> 
>         if (bridge->pci_dev)
>                 pm_runtime_put(&bridge->pci_dev->dev);
> }
> 
> 
> so weirdly it wants bus check on a parent bus, otherwise it will
> not trim devices?  probably a bug, but easy to work around.

Modern docks would use native pcie surprise removal path.

As for ACPI, my old laptop, had an unlock button => _LCK
and that relied on OS processing ACPI events, not so surprise.

There might have been ACPI/hybrid docks that did surprise removal,
but then one need to find one and model after that instead of 
just blanket force removal. (likely out come would a doc device
support only, not an arbitrary device removal)

(not the case described in this series, though. hence my request to clarify 
usecase)

from what I see in spec there is _RMV method that says that device
supports surprise removal that can be used for devices that support it.
However I would hesitate very much to blank apply it to every PCI device.
(it's not even realistic to ask for proving safe tear down across various
drivers and OSes/versions)

Rather than a knee jerk treatment of misconfig consequences,
I'd rather see patches to prevent misconfig in the 1st place
(subj to deprecation but doable).

As for the cases where OS mis-behaves (apcihp thread starvation,...),
fixing guest to follow hotplug contract is a proper place to do it.

On QEMU side we have it covered as well. If unplug was not processed,
mgmt is free to repeat action.

 
> > 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
> > >   
>