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

["Michael S. Tsirkin" <mst@xxxxxxxxxx>]

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.


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