hmp-commands.hx | 11 ++++++----- hw/acpi/acpi-pci-hotplug-stub.c | 6 ++++++ hw/acpi/generic_event_device.c | 15 +++++++++++++++ hw/acpi/ich9.c | 15 +++++++++++++++ hw/acpi/pcihp.c | 17 +++++++++++++++++ hw/acpi/piix4.c | 15 +++++++++++++++ hw/core/hotplug.c | 11 +++++++++++ hw/isa/lpc_ich9.c | 1 + hw/pci/pcie.c | 20 ++++++++++++++++++++ hw/pci/pcie_port.c | 1 + hw/s390x/s390-pci-bus.c | 4 ++-- hw/vfio/ap.c | 2 +- hw/vfio/ccw.c | 2 +- hw/vfio/pci.c | 2 +- hw/xen/xen-legacy-backend.c | 2 +- hw/xen/xen_pvdev.c | 2 +- include/hw/acpi/ich9.h | 2 ++ include/hw/acpi/pcihp.h | 3 +++ include/hw/core/hotplug.h | 12 ++++++++++++ include/hw/core/qdev.h | 2 +- include/hw/pci/pcie.h | 2 ++ qapi/qdev.json | 11 +++++++++-- system/qdev-monitor.c | 23 +++++++++++++++++------ 23 files changed, 160 insertions(+), 21 deletions(-)
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. 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. In this situation, the device may be impossible to remove through normal guest-cooperative hot-unplug. Production environments also need a host side recovery option when the guest kernel is the reason that unplug does not complete. This series adds a force option to QMP device_del and HMP device_del. When requested, QEMU asks the selected hotplug controller to complete the unplug through a new force_unplug callback. This series implements forced unplug for ACPI PCI hotplug and PCIe native hotplug, which cover common pc/q35/virt cases. SHPC is not implemented by this series. Dongli Zhang (8): qdev: Add force argument to qdev_unplug qdev: hotplug: Add force_unplug handler callback qdev: Support forced device_del in QMP and HMP hw/acpi/pcihp: acpi/pcihp: Add forced slot unplug helper hw/acpi/piix4: Support forced PCI unplug hw/acpi/ich9: Support forced PCI unplug hw/acpi/ged: Support forced PCI unplug hw/pci/pcie: Support forced PCIe native unplug hmp-commands.hx | 11 ++++++----- hw/acpi/acpi-pci-hotplug-stub.c | 6 ++++++ hw/acpi/generic_event_device.c | 15 +++++++++++++++ hw/acpi/ich9.c | 15 +++++++++++++++ hw/acpi/pcihp.c | 17 +++++++++++++++++ hw/acpi/piix4.c | 15 +++++++++++++++ hw/core/hotplug.c | 11 +++++++++++ hw/isa/lpc_ich9.c | 1 + hw/pci/pcie.c | 20 ++++++++++++++++++++ hw/pci/pcie_port.c | 1 + hw/s390x/s390-pci-bus.c | 4 ++-- hw/vfio/ap.c | 2 +- hw/vfio/ccw.c | 2 +- hw/vfio/pci.c | 2 +- hw/xen/xen-legacy-backend.c | 2 +- hw/xen/xen_pvdev.c | 2 +- include/hw/acpi/ich9.h | 2 ++ include/hw/acpi/pcihp.h | 3 +++ include/hw/core/hotplug.h | 12 ++++++++++++ include/hw/core/qdev.h | 2 +- include/hw/pci/pcie.h | 2 ++ qapi/qdev.json | 11 +++++++++-- system/qdev-monitor.c | 23 +++++++++++++++++------ 23 files changed, 160 insertions(+), 21 deletions(-) base-commit: eea8fe61b8be8f3016e522e6af24924a0266ca95 Thank you very much! Dongli Zhang
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. > > 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. > > In this situation, the device may be impossible to remove through normal > guest-cooperative hot-unplug. Production environments also need a host side > recovery option when the guest kernel is the reason that unplug does not > complete. > > This series adds a force option to QMP device_del and HMP device_del. When > requested, QEMU asks the selected hotplug controller to complete the unplug > through a new force_unplug callback. > > This series implements forced unplug for ACPI PCI hotplug and PCIe native > hotplug, which cover common pc/q35/virt cases. SHPC is not implemented by > this series. > > > Dongli Zhang (8): > qdev: Add force argument to qdev_unplug > qdev: hotplug: Add force_unplug handler callback > qdev: Support forced device_del in QMP and HMP > hw/acpi/pcihp: acpi/pcihp: Add forced slot unplug helper > hw/acpi/piix4: Support forced PCI unplug > hw/acpi/ich9: Support forced PCI unplug > hw/acpi/ged: Support forced PCI unplug > hw/pci/pcie: Support forced PCIe native unplug > > hmp-commands.hx | 11 ++++++----- > hw/acpi/acpi-pci-hotplug-stub.c | 6 ++++++ > hw/acpi/generic_event_device.c | 15 +++++++++++++++ > hw/acpi/ich9.c | 15 +++++++++++++++ > hw/acpi/pcihp.c | 17 +++++++++++++++++ > hw/acpi/piix4.c | 15 +++++++++++++++ > hw/core/hotplug.c | 11 +++++++++++ > hw/isa/lpc_ich9.c | 1 + > hw/pci/pcie.c | 20 ++++++++++++++++++++ > hw/pci/pcie_port.c | 1 + > hw/s390x/s390-pci-bus.c | 4 ++-- > hw/vfio/ap.c | 2 +- > hw/vfio/ccw.c | 2 +- > hw/vfio/pci.c | 2 +- > hw/xen/xen-legacy-backend.c | 2 +- > hw/xen/xen_pvdev.c | 2 +- > include/hw/acpi/ich9.h | 2 ++ > include/hw/acpi/pcihp.h | 3 +++ > include/hw/core/hotplug.h | 12 ++++++++++++ > include/hw/core/qdev.h | 2 +- > include/hw/pci/pcie.h | 2 ++ > qapi/qdev.json | 11 +++++++++-- > system/qdev-monitor.c | 23 +++++++++++++++++------ > 23 files changed, 160 insertions(+), 21 deletions(-) > > base-commit: eea8fe61b8be8f3016e522e6af24924a0266ca95 > > Thank you very much! > > Dongli Zhang > With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
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. >> >> 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. Thank you very much! Dongli Zhang
On Wed, 26 Aug 2026 09:15:47 -0700 Dongli Zhang <dongli.zhang@oracle.com> 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 >
On Thu, Sep 3, 2026 8:28:35AM -0700, Igor Mammedov wrote: > On Wed, 26 Aug 2026 09:15:47 -0700 > Dongli Zhang <dongli.zhang@oracle.com> 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. Users are generally more tolerant of issues with real hardware. In virtualization and cloud environments, PCI hotplug is more commonly used for NICs and storage devices. Users are less tolerant of disruption or unexpected failures. > >> >> >> >> The non-zero slot case has also been discussed in: >> >> [snip] >> > >> >> 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). By instrumenting the QEMU functions related to device hotplug and PCI initialization, we may be able to make informed assumptions. > > 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. Here are some use cases in virtualization and cloud environments: 1. Suppose there is a QEMU user configuration error and a PCI device is attached to slot 1 of a pcie-root-port that uses ACPI-based hotplug. The device may not be detected or ejected. As a result, there is no way to detach it from the user's QEMU instance until the guest VM reboots. 2. For an unknown reason in the customer's guest kernel (Linux, Windows, or BSD), a PCI device may still be referenced by the guest kernel or its services. As a result, the guest never writes the eject register for ACPI-based hotplug, and QEMU cannot detach the device. The customer may blame QEMU for not removing it. A force-detach option could provide an escape hatch, with a warning that it may make the VM unstable or insecure. 3. Suppose a VM is stuck because of a guest kernel bug, such as a Linux kernel panic without a kdump kernel being triggered. The guest kernel is unresponsive. Force detach could allow the block device to be temporarily attached to another VM without resetting the currently panicked VM. 4. Provide a mechanism to demonstrate that force detach is unsafe. Otherwise, users may repeatedly attempt it and mistakenly conclude that QEMU is at fault :) Thank you very much! Dongli Zhang > > 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 >> >
On Mon, Sep 07, 2026 at 01:26:57AM -0700, Dongli Zhang wrote: > > > On Thu, Sep 3, 2026 8:28:35AM -0700, Igor Mammedov wrote: > > On Wed, 26 Aug 2026 09:15:47 -0700 > > Dongli Zhang <dongli.zhang@oracle.com> 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. > > Users are generally more tolerant of issues with real hardware. > > In virtualization and cloud environments, PCI hotplug is more commonly used for > NICs and storage devices. Users are less tolerant of disruption or unexpected > failures. Simply put, surprise removal exists in the hardware. Emulating that makes sense, at a high level. Nor is it too hard. However, guests, especially Linux, do not handle it all that well generally. Exactly because users would tend to impatiently reach for that tool, then blame QEMU after a crash, we avoided emulating that. I'd expect much more in the way of research into how guests behave, perhaps some ways to limit it to devices that work well, and likely some linux patches to make it work better, before we commit to supporting such interfaces. > > > >> >> > >> >> The non-zero slot case has also been discussed in: > >> >> > > [snip] > > >> > > >> > >> 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). > > By instrumenting the QEMU functions related to device hotplug and PCI > initialization, we may be able to make informed assumptions. So try. But just know that pci initialization is commonly done by firmware, not the driver. > > > > 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. > > Here are some use cases in virtualization and cloud environments: > > 1. Suppose there is a QEMU user configuration error and a PCI device is attached > to slot 1 of a pcie-root-port that uses ACPI-based hotplug. The device may not > be detected or ejected. As a result, there is no way to detach it from the > user's QEMU instance until the guest VM reboots. sounds vague. if users can not configure qemu what are the chances they will use force detach responsibly? > 2. For an unknown reason in the customer's guest kernel (Linux, Windows, or > BSD), a PCI device may still be referenced by the guest kernel or its services. > As a result, the guest never writes the eject register for ACPI-based hotplug, > and QEMU cannot detach the device. The customer may blame QEMU for not removing > it. A force-detach option could provide an escape hatch, with a warning that it > may make the VM unstable or insecure. So just reboot the guest. > 3. Suppose a VM is stuck because of a guest kernel bug, such as a Linux kernel > panic without a kdump kernel being triggered. The guest kernel is unresponsive. > Force detach could allow the block device to be temporarily attached to another > VM without resetting the currently panicked VM. So just reboot the guest. > 4. Provide a mechanism to demonstrate that force detach is unsafe. Otherwise, > users may repeatedly attempt it and mistakenly conclude that QEMU is at fault :) We have that - we don't support unsafe detach. > Thank you very much! > > Dongli Zhang > > > > > 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 > >> > >
On Mon, Sep 7, 2026 1:55:42AM -0700, Michael S. Tsirkin wrote: > On Mon, Sep 07, 2026 at 01:26:57AM -0700, Dongli Zhang wrote: >> >> >> On Thu, Sep 3, 2026 8:28:35AM -0700, Igor Mammedov wrote: >> > On Wed, 26 Aug 2026 09:15:47 -0700 >> > Dongli Zhang <dongli.zhang@oracle.com> 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. >> >> Users are generally more tolerant of issues with real hardware. >> >> In virtualization and cloud environments, PCI hotplug is more commonly used for >> NICs and storage devices. Users are less tolerant of disruption or unexpected >> failures. > > > Simply put, surprise removal exists in the hardware. Emulating that > makes sense, at a high level. Nor is it too hard. > However, guests, especially Linux, do not > handle it all that well generally. Exactly because users > would tend to impatiently reach for that tool, then > blame QEMU after a crash, we avoided emulating that. > > > I'd expect much more in the way of research into how guests behave, > perhaps some ways to limit it to devices that work well, and > likely some linux patches to make it work better, before we commit to > supporting such interfaces. Here is my summary of the current situation and plan: 1. Folks are not against adding an option to force-detach a PCI device. It should emulate surprise removal, which exists in real hardware. This requires adding the emulation to QEMU. 2. However, the more important issue is ensuring that surprise removal works well in guest operating systems, such as Linux and Windows, and for a defined subset of devices, including virtio devices, VFIO-assigned devices, Intel, Mellanox, and Broadcom NICs, and NVMe devices. From QEMU’s perspective, it is preferable not to expose an interface that may cause a guest crash and lead users to blame QEMU for a guest-side limitation. 3. More research and development work is required to support surprise removal in both QEMU and guest operating systems, especially the Linux kernel. 4. So far, from QEMU's perspective, everyone suggest rebooting the guest VM for many of the use cases I mentioned 5. By instrumenting QEMU code and possibly adding additional metadata, we can track whether a PCI device has been accessed by the guest VM, especially during PCI hotplug. If the device has never been used by the guest VM, it may be safer to force-detach it. > > >> > >> >> >> >> >> >> The non-zero slot case has also been discussed in: >> >> >> >> >> [snip] >> >> >> > >> >> >> >> 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). >> >> By instrumenting the QEMU functions related to device hotplug and PCI >> initialization, we may be able to make informed assumptions. > > So try. But just know that pci initialization is commonly done by firmware, not > the driver. Thank you very much for the confirmation. This also provides users with telemetry to narrow down the potential reasons why QEMU does not send the DEVICE_DELETED QMP event. > >> > >> > 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. >> >> Here are some use cases in virtualization and cloud environments: >> >> 1. Suppose there is a QEMU user configuration error and a PCI device is attached >> to slot 1 of a pcie-root-port that uses ACPI-based hotplug. The device may not >> be detected or ejected. As a result, there is no way to detach it from the >> user's QEMU instance until the guest VM reboots. > > sounds vague. if users can not configure qemu what are the chances > they will use force detach responsibly? I should have clarified the difference between the QEMU user and the VM owner. The QEMU user is the software that manages VMs, such as libvirt or any other software that communicates with QEMU through QMP. The VM owner does not have access to QEMU. However, any mistake made by the QEMU user can affect the VM owner. For example, if the QEMU user mistakenly adds a PCI device to slot 1 of a pcie-root-port, the VM owner cannot detach the device from the QEMU instance until the guest reboots. In this case, the QEMU user is at fault, but the VM owner is affected. A force or surprise removal option helps the QEMU user recover from a configuration error without requiring action from the VM owner. > >> 2. For an unknown reason in the customer's guest kernel (Linux, Windows, or >> BSD), a PCI device may still be referenced by the guest kernel or its services. >> As a result, the guest never writes the eject register for ACPI-based hotplug, >> and QEMU cannot detach the device. The customer may blame QEMU for not removing >> it. A force-detach option could provide an escape hatch, with a warning that it >> may make the VM unstable or insecure. > > So just reboot the guest. I agree. Sometimes, the VM owner blames QEMU for not detaching a PCI device, even though QEMU is technically waiting for the guest VM to write to the EJ register :( > >> 3. Suppose a VM is stuck because of a guest kernel bug, such as a Linux kernel >> panic without a kdump kernel being triggered. The guest kernel is unresponsive. >> Force detach could allow the block device to be temporarily attached to another >> VM without resetting the currently panicked VM. > > So just reboot the guest. I agree. Sometimes, the VM owner blames QEMU for not detaching a PCI device, even though QEMU is technically waiting for the guest VM to write to the EJ register :( > >> 4. Provide a mechanism to demonstrate that force detach is unsafe. Otherwise, >> users may repeatedly attempt it and mistakenly conclude that QEMU is at fault :) > > We have that - we don't support unsafe detach. Thank you very much! Dongli Zhang
On Mon, Sep 07, 2026 at 02:06:29PM -0700, Dongli Zhang wrote: > 5. By instrumenting QEMU code and possibly adding additional metadata, we can > track whether a PCI device has been accessed by the guest VM, especially during > PCI hotplug. If the device has never been used by the guest VM, it may be safer > to force-detach it. this last one I am not sure about. as I said, devices are commonly accessed by firmware.
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@oracle.com> 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
> >
On Thu, 3 Sep 2026 16:17:20 -0400
"Michael S. Tsirkin" <mst@redhat.com> 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@oracle.com> 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
> > >
>
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@redhat.com> 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@oracle.com> 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.
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.
>
> > > 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
> > > >
> >
On Fri, 4 Sep 2026 07:22:10 -0400
"Michael S. Tsirkin" <mst@redhat.com> 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@redhat.com> 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@oracle.com> 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.
>
>
> 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.
> > > > 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
> > > > >
> > >
>
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@redhat.com> 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@redhat.com> 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@oracle.com> 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
© 2016 - 2026 Red Hat, Inc.