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

[Dongli Zhang <dongli.zhang@xxxxxxxxxx>]

On Fri, Sep 4, 2026 5:08:24AM -0700, Igor Mammedov wrote:
> On Fri, 4 Sep 2026 07:22:10 -0400
> "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote:
> 
>> On Fri, Sep 04, 2026 at 01:07:09PM +0200, Igor Mammedov wrote:
>> > 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.
>> > > > 

[snip]

>> > > > > > 
>> > > > > > 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.  
>> 
>> 
>> Sorry if I am unclear. I just meant that it looks like we
>> can support surprise removal with ACPI just by reporting
>> bus check events on the parent.
> 
> maybe, but that ain't SPECed and might be OS specific.
> 
> The way I've read the cover letter, that won't work for mentioned mis-config 
> cases.
> Also what would happen on bus-check 'cleanup' would be a lottery.
> hence I'm for being safe here.
> 
> It's better to implement native PCIE surprise removal if that's really needed.
> 

Suppose many x86 users use q35 and pcie-root-port. Since commit 17858a169508
("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35"), ACPI-based hotplug
has been the default for q35. arm64 still uses native PCIe hotplug.

Therefore, in my opinion, it is more crucial to support ACPI-based hotplug than
native PCIe hotplug. In addition, native PCIe hotplug can still detach a PCI
device even when the device is erroneously attached to slot 1 of a 
pcie-root-port.

Although surprise removal is not explicitly specified and may be OS-specific, my
understanding is that it involves two steps:

1. Force-detach the PCI device.
2. Use a mechanism to notify the guest VM that the device is no longer present.

Therefore, may I assume that this can address the use cases mentioned in the
cover letter?

Thank you very much!

Dongli Zhang