Currently ACPI PCI hotplug is enabled by default for Q35 machine type and overrides native PCIe hotplug. It works as expected when a PCIe device is hotplugged into slot, however the device becomes in-operational after migration. Which is caused by BARs being disabled on target due to powered off status of the slot.
Proposed fix disables power control on PCIe slot when ACPI pcihp takes over hotplug control and makes PCIe slot check if power control is enabled before trying to change slot's power. Which leaves slot always powered on and that makes PCI core keep BARs enabled. PS: it's still hacky approach as all ACPI PCI hotplug is, but it's the least intrusive one. Alternative, I've considered, could be chaining hotplug callbacks and making pcihp ones call overriden native callbacks while inhibiting hotplug event in native callbacks somehow. But that were a bit more intrusive and spills over to SHPC if implemented systematically, so I ditched that for now. It could be resurrected later on if current approach turns out to be insufficient. RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2053584 CC: m...@redhat.com CC: kra...@redhat.com Igor Mammedov (4): pci: expose TYPE_XIO3130_DOWNSTREAM name pcie: update slot power status only is power control is enabled acpi: pcihp: disable power control on PCIe slot q35: compat: keep hotplugged PCIe device broken after migration for 6.2-older machine types include/hw/acpi/pcihp.h | 4 +++- include/hw/pci-bridge/xio3130_downstream.h | 15 +++++++++++++++ hw/acpi/acpi-pci-hotplug-stub.c | 3 ++- hw/acpi/ich9.c | 21 ++++++++++++++++++++- hw/acpi/pcihp.c | 16 +++++++++++++++- hw/acpi/piix4.c | 3 ++- hw/core/machine.c | 4 +++- hw/pci-bridge/xio3130_downstream.c | 3 ++- hw/pci/pcie.c | 5 ++--- 9 files changed, 64 insertions(+), 10 deletions(-) create mode 100644 include/hw/pci-bridge/xio3130_downstream.h -- 2.31.1