| Message ID | 20240625035224.13019-1-gaoshiyuan@baidu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load | expand |
On Tue, 25 Jun 2024 11:52:24 +0800 Shiyuan Gao <gaoshiyuan@baidu.com> wrote: > SHPC driver will be loaded fail in i440fx machine, the dmesg shows > that OS cannot get control of SHPC hotplug and hotplug device to > the PCI bridge will fail when we use SHPC Native type: > > [3.336059] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S28_) > [3.337408] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > [3.338710] shpchp 0000:00:03.0: Cannot get control of SHPC hotplug > > Add OSHP method support for transfer control to the operating system, > after this SHPC driver will be loaded success and the hotplug device to > the PCI bridge will success when we use SHPC Native type. > > [1.703975] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S18_) > [1.704934] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > [1.705855] shpchp 0000:00:03.0: Gained control of SHPC hotplug (\_SB_.PCI0) > [1.707054] shpchp 0000:00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 please describe in commit message reproducer (aka QEMU CLI and guest OS and if necessary other details) > Signed-off-by: Shiyuan Gao <gaoshiyuan@baidu.com> > --- > v1 -> v2: > * add quote PCI firmware spec 3.0 > * explain why an empty method is enough > --- > > hw/i386/acpi-build.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c > index f4e366f64f..00f8abedf6 100644 > --- a/hw/i386/acpi-build.c > +++ b/hw/i386/acpi-build.c > @@ -1412,6 +1412,23 @@ static void build_acpi0017(Aml *table) > aml_append(table, scope); > } > > +/* > + * PCI Firmware Specification 3.0 > + * 4.8. The OSHP Control Method > + */ > +static Aml *build_oshp_method(void) > +{ > + Aml *method; > + > + /* > + * We don't use ACPI to control the SHPC, so just return > + * success is enough. > + */ > + method = aml_method("OSHP", 0, AML_NOTSERIALIZED); > + aml_append(method, aml_return(aml_int(0x0))); > + return method; > +} > + > static void > build_dsdt(GArray *table_data, BIOSLinker *linker, > AcpiPmInfo *pm, AcpiMiscInfo *misc, > @@ -1452,6 +1469,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); > aml_append(dev, aml_name_decl("_UID", aml_int(pcmc->pci_root_uid))); > aml_append(dev, aml_pci_edsm()); > + aml_append(dev, build_oshp_method()); it's global and what will happen if we have ACPI PCI hotplug enabled and guest calls this NOP method? > aml_append(sb_scope, dev); > aml_append(dsdt, sb_scope); > > @@ -1586,6 +1604,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, > aml_append(dev, build_q35_osc_method(true)); > } else { > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); > + aml_append(dev, build_oshp_method()); > } > > if (numa_node != NUMA_NODE_UNASSIGNED) {
> > that OS cannot get control of SHPC hotplug and hotplug device to > > the PCI bridge will fail when we use SHPC Native type: > > > > [3.336059] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S28_) > > [3.337408] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > > [3.338710] shpchp 0000:00:03.0: Cannot get control of SHPC hotplug > > > > Add OSHP method support for transfer control to the operating system, > > after this SHPC driver will be loaded success and the hotplug device to > > the PCI bridge will success when we use SHPC Native type. > > > > [1.703975] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S18_) > > [1.704934] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > > [1.705855] shpchp 0000:00:03.0: Gained control of SHPC hotplug (\_SB_.PCI0) > > [1.707054] shpchp 0000:00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 > > please describe in commit message reproducer > (aka QEMU CLI and guest OS and if necessary other details) qemu-system-x86_64 -machine pc-q35-9.0 ... -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off guest OS: centos7/ubuntu22.04 I will add it in the next version. > > +/* > > + * PCI Firmware Specification 3.0 > > + * 4.8. The OSHP Control Method > > + */ > > +static Aml *build_oshp_method(void) > > +{ > > + Aml *method; > > + > > + /* > > + * We don't use ACPI to control the SHPC, so just return > > + * success is enough. > > + */ > > + method = aml_method("OSHP", 0, AML_NOTSERIALIZED); > > + aml_append(method, aml_return(aml_int(0x0))); > > + return method; > > +} > > + > > static void > > build_dsdt(GArray *table_data, BIOSLinker *linker, > > AcpiPmInfo *pm, AcpiMiscInfo *misc, > > @@ -1452,6 +1469,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, > > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); > > aml_append(dev, aml_name_decl("_UID", aml_int(pcmc->pci_root_uid))); > > aml_append(dev, aml_pci_edsm()); > > + aml_append(dev, build_oshp_method()); > > it's global and what will happen if we have ACPI PCI hotplug enabled > and guest calls this NOP method? ths OS get the control of SHPC hotplug and SHPC driver load fail later. [ 6.170345] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S18_) [ 6.171962] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) [ 6.173556] shpchp 0000:00:03.0: Gained control of SHPC hotplug (\_SB_.PCI0) [ 6.175144] shpchp 0000:00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 [ 6.196153] shpchp 0000:00:03.0: irq 24 for MSI/MSI-X [ 6.197211] shpchp 0000:00:03.0: pci_hp_register failed with error -16 [ 6.198272] shpchp 0000:00:03.0: Slot initialization failed this looks more suitable. + if (!pm->pcihp_bridge_en) { + aml_append(dev, build_i440fx_oshp_method()); + } > > > aml_append(sb_scope, dev); > > aml_append(dsdt, sb_scope); > > > > @@ -1586,6 +1604,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, > > aml_append(dev, build_q35_osc_method(true)); > > } else { > > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); > > + aml_append(dev, build_oshp_method()); > > } > > > > if (numa_node != NUMA_NODE_UNASSIGNED) { Hot plug/unplug a device using SHPC will take more time than ACPI PCI hotplug, because after pressing the button, it can be cancelled within 5 seconds in SHPC driver. If I want to use ACPI PCI hotplug in the pxb bridge, what else need to be done? thanks.
> > > that OS cannot get control of SHPC hotplug and hotplug device to > > > the PCI bridge will fail when we use SHPC Native type: > > > > > > [3.336059] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S28_) > > > [3.337408] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > > > [3.338710] shpchp 0000:00:03.0: Cannot get control of SHPC hotplug > > > > > > Add OSHP method support for transfer control to the operating system, > > > after this SHPC driver will be loaded success and the hotplug device to > > > the PCI bridge will success when we use SHPC Native type. > > > > > > [1.703975] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S18_) > > > [1.704934] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > > > [1.705855] shpchp 0000:00:03.0: Gained control of SHPC hotplug (\_SB_.PCI0) > > > [1.707054] shpchp 0000:00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 > > > > please describe in commit message reproducer > > (aka QEMU CLI and guest OS and if necessary other details) > > qemu-system-x86_64 -machine pc-q35-9.0 sorry, it is -machine pc-i440fx-9.0 > ... > -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off >
On Fri, 28 Jun 2024 03:04:28 +0000 "Gao,Shiyuan" <gaoshiyuan@baidu.com> wrote: > > > that OS cannot get control of SHPC hotplug and hotplug device to > > > the PCI bridge will fail when we use SHPC Native type: > > > > > > [3.336059] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S28_) > > > [3.337408] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > > > [3.338710] shpchp 0000:00:03.0: Cannot get control of SHPC hotplug > > > > > > Add OSHP method support for transfer control to the operating system, > > > after this SHPC driver will be loaded success and the hotplug device to > > > the PCI bridge will success when we use SHPC Native type. > > > > > > [1.703975] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S18_) > > > [1.704934] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > > > [1.705855] shpchp 0000:00:03.0: Gained control of SHPC hotplug (\_SB_.PCI0) > > > [1.707054] shpchp 0000:00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 > > > > please describe in commit message reproducer > > (aka QEMU CLI and guest OS and if necessary other details) > > qemu-system-x86_64 -machine pc-q35-9.0 > ... > -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off please use full QEMU CLI and follow up steps to trigger the issue. From above it's not obvious what and where you are trying to hotplug > guest OS: centos7/ubuntu22.04 > > I will add it in the next version. > > > > +/* > > > + * PCI Firmware Specification 3.0 > > > + * 4.8. The OSHP Control Method > > > + */ > > > +static Aml *build_oshp_method(void) > > > +{ > > > + Aml *method; > > > + > > > + /* > > > + * We don't use ACPI to control the SHPC, so just return > > > + * success is enough. > > > + */ > > > + method = aml_method("OSHP", 0, AML_NOTSERIALIZED); > > > + aml_append(method, aml_return(aml_int(0x0))); > > > + return method; > > > +} > > > + > > > static void > > > build_dsdt(GArray *table_data, BIOSLinker *linker, > > > AcpiPmInfo *pm, AcpiMiscInfo *misc, > > > @@ -1452,6 +1469,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, > > > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); > > > aml_append(dev, aml_name_decl("_UID", aml_int(pcmc->pci_root_uid))); > > > aml_append(dev, aml_pci_edsm()); > > > + aml_append(dev, build_oshp_method()); > > > > it's global and what will happen if we have ACPI PCI hotplug enabled > > and guest calls this NOP method? > > ths OS get the control of SHPC hotplug and SHPC driver load fail later. > > [ 6.170345] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S18_) > [ 6.171962] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > [ 6.173556] shpchp 0000:00:03.0: Gained control of SHPC hotplug (\_SB_.PCI0) > [ 6.175144] shpchp 0000:00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 > [ 6.196153] shpchp 0000:00:03.0: irq 24 for MSI/MSI-X > [ 6.197211] shpchp 0000:00:03.0: pci_hp_register failed with error -16 > [ 6.198272] shpchp 0000:00:03.0: Slot initialization failed > > this looks more suitable. > > + if (!pm->pcihp_bridge_en) { > + aml_append(dev, build_i440fx_oshp_method()); > + } we also have PIIX4_PM.acpi-root-pci-hotplug (default true) though it seems that ACPI hotplug takes precedence of SHPC if both are enabled. So I'd take it and OSHP approach seems simpler than adding _OSC to do the same. > > > > > > aml_append(sb_scope, dev); > > > aml_append(dsdt, sb_scope); > > > > > > @@ -1586,6 +1604,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, > > > aml_append(dev, build_q35_osc_method(true)); > > > } else { > > > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); > > > + aml_append(dev, build_oshp_method()); > > > } > > > > > > if (numa_node != NUMA_NODE_UNASSIGNED) { > > Hot plug/unplug a device using SHPC will take more time than ACPI PCI hotplug, because > after pressing the button, it can be cancelled within 5 seconds in SHPC driver. for SHPC on PXB see, commit d10dda2d60 hw/pci-bridge: disable SHPC in PXB it seems that enabling SHPC on PXB in QEMU is not enough, UEFI needs to support that as well (CCing Gerd to check whether it is possible at all) > If I want to use ACPI PCI hotplug in the pxb bridge, what else need to be done? does it have to be hotplug directly into pxb or would be it be sufficient to have hotplug support on pci-bridge attached to a pxb? I particularly do not like spreading ACPI hotplug to any host bridges, as it's quite complicated code. Michael, Are there any reasons why we don't have hotplug directly on PXBs enabled from PCI spec point of view? (Is it that host bridges just do not support hotplug into them?) > thanks. >
> > > > the PCI bridge will fail when we use SHPC Native type: > > > > > > > > [3.336059] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S28_) > > > > [3.337408] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > > > > [3.338710] shpchp 0000:00:03.0: Cannot get control of SHPC hotplug > > > > > > > > Add OSHP method support for transfer control to the operating system, > > > > after this SHPC driver will be loaded success and the hotplug device to > > > > the PCI bridge will success when we use SHPC Native type. > > > > > > > > [1.703975] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S18_) > > > > [1.704934] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > > > > [1.705855] shpchp 0000:00:03.0: Gained control of SHPC hotplug (\_SB_.PCI0) > > > > [1.707054] shpchp 0000:00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 > > > > > > please describe in commit message reproducer > > > (aka QEMU CLI and guest OS and if necessary other details) > > > > qemu-system-x86_64 -machine pc-q35-9.0 > > ... > > -global PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off > > please use full QEMU CLI and follow up steps to trigger the issue. > > From above it's not obvious what and where you are trying to hotplug Nothing needs to be done when you start a i440fx VM, this issue will be triggered. PIIX4_PM.acpi-pci-hotplug-with-bridge-support=off is used to verify shpc driver load sucess. > > > guest OS: centos7/ubuntu22.04 > > > > I will add it in the next version. > > > > > > +/* > > > > + * PCI Firmware Specification 3.0 > > > > + * 4.8. The OSHP Control Method > > > > + */ > > > > +static Aml *build_oshp_method(void) > > > > +{ > > > > + Aml *method; > > > > + > > > > + /* > > > > + * We don't use ACPI to control the SHPC, so just return > > > > + * success is enough. > > > > + */ > > > > + method = aml_method("OSHP", 0, AML_NOTSERIALIZED); > > > > + aml_append(method, aml_return(aml_int(0x0))); > > > > + return method; > > > > +} > > > > + > > > > static void > > > > build_dsdt(GArray *table_data, BIOSLinker *linker, > > > > AcpiPmInfo *pm, AcpiMiscInfo *misc, > > > > @@ -1452,6 +1469,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, > > > > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); > > > > aml_append(dev, aml_name_decl("_UID", aml_int(pcmc->pci_root_uid))); > > > > aml_append(dev, aml_pci_edsm()); > > > > + aml_append(dev, build_oshp_method()); > > > > > > it's global and what will happen if we have ACPI PCI hotplug enabled > > > and guest calls this NOP method? > > > > ths OS get the control of SHPC hotplug and SHPC driver load fail later. > > > > [ 6.170345] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S18_) > > [ 6.171962] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) > > [ 6.173556] shpchp 0000:00:03.0: Gained control of SHPC hotplug (\_SB_.PCI0) > > [ 6.175144] shpchp 0000:00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 > > [ 6.196153] shpchp 0000:00:03.0: irq 24 for MSI/MSI-X > > [ 6.197211] shpchp 0000:00:03.0: pci_hp_register failed with error -16 > > [ 6.198272] shpchp 0000:00:03.0: Slot initialization failed > > > > this looks more suitable. > > > > + if (!pm->pcihp_bridge_en) { > > + aml_append(dev, build_i440fx_oshp_method()); > > + } > > we also have > PIIX4_PM.acpi-root-pci-hotplug (default true) > though it seems that ACPI hotplug takes precedence of SHPC if both are enabled. > So I'd take it and OSHP approach seems simpler than adding _OSC to do the same. yes, I tried to add an OSC method, but the OS and the firmware failed to negotiate in the guest, dmesg as follow. Through analyzing the code, I found that this process relies on pci_ext_cfg_avail in negotiate_os_control. On i440fx, pci_ext_cfg_avail is false. [ 0.631156] acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MSI EDR HPX-Type3] [ 0.632184] acpi PNP0A03:00: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI] [ 0.633160] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge. Therefore, I chose the OSHP method. > > > > > > > > > > aml_append(sb_scope, dev); > > > > aml_append(dsdt, sb_scope); > > > > > > > > @@ -1586,6 +1604,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, > > > > aml_append(dev, build_q35_osc_method(true)); > > > > } else { > > > > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); > > > > + aml_append(dev, build_oshp_method()); > > > > } > > > > > > > > if (numa_node != NUMA_NODE_UNASSIGNED) { > > > > Hot plug/unplug a device using SHPC will take more time than ACPI PCI hotplug, because > > after pressing the button, it can be cancelled within 5 seconds in SHPC driver. > > for SHPC on PXB see, > commit d10dda2d60 hw/pci-bridge: disable SHPC in PXB > > it seems that enabling SHPC on PXB in QEMU is not enough, > UEFI needs to support that as well > (CCing Gerd to check whether it is possible at all) > > > If I want to use ACPI PCI hotplug in the pxb bridge, what else need to be done? > > does it have to be hotplug directly into pxb or > would be it be sufficient to have hotplug support > on pci-bridge attached to a pxb? It's sufficient to hotplug support on pci-bridge attached to a pxb. > > I particularly do not like spreading ACPI hotplug > to any host bridges, as it's quite complicated > code. >
Hi, > > for SHPC on PXB see, > > commit d10dda2d60 hw/pci-bridge: disable SHPC in PXB > > > > it seems that enabling SHPC on PXB in QEMU is not enough, > > UEFI needs to support that as well > > (CCing Gerd to check whether it is possible at all) Hmm, can't give a quick answer on that. From the commit message it doesn't look easy ... > > > If I want to use ACPI PCI hotplug in the pxb bridge, what else need to be done? > > > > does it have to be hotplug directly into pxb or > > would be it be sufficient to have hotplug support > > on pci-bridge attached to a pxb? > > It's sufficient to hotplug support on pci-bridge attached to a pxb. ... but I guess using this instead would be better anyway? take care, Gerd
> > > > If I want to use ACPI PCI hotplug in the pxb bridge, what else need to be done? > > > > > > does it have to be hotplug directly into pxb or > > > would be it be sufficient to have hotplug support > > > on pci-bridge attached to a pxb? > > > > It's sufficient to hotplug support on pci-bridge attached to a pxb. > > ... but I guess using this instead would be better anyway? https://lore.kernel.org/all/20220422135101.65796823@redhat.com/t/#r831d589f243c24334a09995620b74408847a87a0 According this message, It seems that the current QEMU does not support it yet. I tried to hotplug on pci-bridge attached to a pxb, no device found in the guest. > > take care, > Gerd
On Mon, 1 Jul 2024 14:27:50 +0000 "Gao,Shiyuan" <gaoshiyuan@baidu.com> wrote: > > > > > If I want to use ACPI PCI hotplug in the pxb bridge, what else need to be done? > > > > > > > > does it have to be hotplug directly into pxb or > > > > would be it be sufficient to have hotplug support > > > > on pci-bridge attached to a pxb? > > > > > > It's sufficient to hotplug support on pci-bridge attached to a pxb. > > > > ... but I guess using this instead would be better anyway? > > https://lore.kernel.org/all/20220422135101.65796823@redhat.com/t/#r831d589f243c24334a09995620b74408847a87a0 > > According this message, It seems that the current QEMU does not support it yet. > I tried to hotplug on pci-bridge attached to a pxb, no device found in the guest. SHPC works for q35, which provides _OSC. It is broken for pc machine though, since machine lacks either _OSC or OSHP. Theoretically SHPC should still work for hotplugged bridges (i.e. with ACPI hotplug enabled, when one hotplugs a bridge into pci.0, but I haven't tried that lately) I'm still not sure if we should make OSHP global, or put it only under bridges that have shcp=on && don't have ACPI hotplug. The later seems cleaner though. > > > > take care, > > Gerd >
> > > > > > If I want to use ACPI PCI hotplug in the pxb bridge, what else need to be done? > > > > > > > > > > does it have to be hotplug directly into pxb or > > > > > would be it be sufficient to have hotplug support > > > > > on pci-bridge attached to a pxb? > > > > > > > > It's sufficient to hotplug support on pci-bridge attached to a pxb. > > > > > > ... but I guess using this instead would be better anyway? > > > > https://lore.kernel.org/all/20220422135101.65796823@redhat.com/t/#r831d589f243c24334a09995620b74408847a87a0 > > > > According this message, It seems that the current QEMU does not support it yet. > > I tried to hotplug on pci-bridge attached to a pxb, no device found in the guest. > SHPC works for q35, which provides _OSC. > It is broken for pc machine though, since machine lacks either _OSC or OSHP. > Theoretically SHPC should still work for hotplugged bridges > (i.e. with ACPI hotplug enabled, when one hotplugs a bridge into > pci.0, but I haven't tried that lately) > I'm still not sure if we should make OSHP global, or put it only > under bridges that have shcp=on && don't have ACPI hotplug. > The later seems cleaner though. _OSC is global, setting the OSHP method to global also makes sense? Of course，the later seems cleaner. Add the OSHP method and shpc=on, hotplug device to pci-bridge attached to a pxb was sucessful. What do I need to add to the QEMU if I want to use the ACPI pci hotplug under the pci-bridge attached to a pxb? Thanks.
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index f4e366f64f..00f8abedf6 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -1412,6 +1412,23 @@ static void build_acpi0017(Aml *table) aml_append(table, scope); } +/* + * PCI Firmware Specification 3.0 + * 4.8. The OSHP Control Method + */ +static Aml *build_oshp_method(void) +{ + Aml *method; + + /* + * We don't use ACPI to control the SHPC, so just return + * success is enough. + */ + method = aml_method("OSHP", 0, AML_NOTSERIALIZED); + aml_append(method, aml_return(aml_int(0x0))); + return method; +} + static void build_dsdt(GArray *table_data, BIOSLinker *linker, AcpiPmInfo *pm, AcpiMiscInfo *misc, @@ -1452,6 +1469,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); aml_append(dev, aml_name_decl("_UID", aml_int(pcmc->pci_root_uid))); aml_append(dev, aml_pci_edsm()); + aml_append(dev, build_oshp_method()); aml_append(sb_scope, dev); aml_append(dsdt, sb_scope); @@ -1586,6 +1604,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker, aml_append(dev, build_q35_osc_method(true)); } else { aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03"))); + aml_append(dev, build_oshp_method()); } if (numa_node != NUMA_NODE_UNASSIGNED) {
SHPC driver will be loaded fail in i440fx machine, the dmesg shows that OS cannot get control of SHPC hotplug and hotplug device to the PCI bridge will fail when we use SHPC Native type: [3.336059] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S28_) [3.337408] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) [3.338710] shpchp 0000:00:03.0: Cannot get control of SHPC hotplug Add OSHP method support for transfer control to the operating system, after this SHPC driver will be loaded success and the hotplug device to the PCI bridge will success when we use SHPC Native type. [1.703975] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S18_) [1.704934] shpchp 0000:00:03.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0) [1.705855] shpchp 0000:00:03.0: Gained control of SHPC hotplug (\_SB_.PCI0) [1.707054] shpchp 0000:00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0 ss_did 0 Signed-off-by: Shiyuan Gao <gaoshiyuan@baidu.com> --- v1 -> v2: * add quote PCI firmware spec 3.0 * explain why an empty method is enough --- hw/i386/acpi-build.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)