Re: [v2 1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load
> > > > > > 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.65796...@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.
Re: [v2 1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load
On Mon, 1 Jul 2024 14:27:50 + "Gao,Shiyuan" 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.65796...@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 >
Re: [v2 1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load
> > > > 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.65796...@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
Re: [v2 1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load
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
Re: [v2 1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load
> > > > the PCI bridge will fail when we use SHPC Native type:
> > > >
> > > > [3.336059] shpchp :00:03.0: Requesting control of SHPC hotplug
> > > >via OSHP (\_SB_.PCI0.S28_)
> > > > [3.337408] shpchp :00:03.0: Requesting control of SHPC hotplug
> > > >via OSHP (\_SB_.PCI0)
> > > > [3.338710] shpchp :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 :00:03.0: Requesting control of SHPC hotplug
> > > >via OSHP (\_SB_.PCI0.S18_)
> > > > [1.704934] shpchp :00:03.0: Requesting control of SHPC hotplug
> > > >via OSHP (\_SB_.PCI0)
> > > > [1.705855] shpchp :00:03.0: Gained control of SHPC hotplug
> > > >(\_SB_.PCI0)
> > > > [1.707054] shpchp :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 :00:03.0: Requesting control of SHPC hotplug via
> > OSHP (\_SB_.PCI0.S18_)
> > [ 6.171962] shpchp :00:03.0: Requesting control of SHPC hotplug via
> > OSHP (\_SB_.PCI0)
> > [ 6.173556] shpchp :00:03.0: Gained control of SHPC hotplug
> > (\_SB_.PCI0)
> > [ 6.175144] shpchp :00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0
> > ss_did 0
> > [ 6.196153] shpchp :00:03.0: irq 24 for MSI/MSI-X
> > [ 6.197211] shpchp :00:03.0: pci_hp_register failed with error -16
> > [ 6.198272] shpchp :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());
> > > > }
> > > >
> > > >
Re: [v2 1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load
On Fri, 28 Jun 2024 03:04:28 +
"Gao,Shiyuan" 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 :00:03.0: Requesting control of SHPC hotplug via
> > >OSHP (\_SB_.PCI0.S28_)
> > > [3.337408] shpchp :00:03.0: Requesting control of SHPC hotplug via
> > >OSHP (\_SB_.PCI0)
> > > [3.338710] shpchp :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 :00:03.0: Requesting control of SHPC hotplug via
> > >OSHP (\_SB_.PCI0.S18_)
> > > [1.704934] shpchp :00:03.0: Requesting control of SHPC hotplug via
> > >OSHP (\_SB_.PCI0)
> > > [1.705855] shpchp :00:03.0: Gained control of SHPC hotplug
> > >(\_SB_.PCI0)
> > > [1.707054] shpchp :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 :00:03.0: Requesting control of SHPC hotplug via
> OSHP (\_SB_.PCI0.S18_)
> [6.171962] shpchp :00:03.0: Requesting control of SHPC hotplug via
> OSHP (\_SB_.PCI0)
> [6.173556] shpchp :00:03.0: Gained control of SHPC hotplug
> (\_SB_.PCI0)
> [6.175144] shpchp :00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0
> ss_did 0
> [6.196153] shpchp :00:03.0: irq 24 for MSI/MSI-X
> [6.197211] shpchp :00:03.0: pci_hp_register failed with error -16
> [6.198272] shpchp :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
Re: [v2 1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load
> > > 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 :00:03.0: Requesting control of SHPC hotplug via > > > OSHP (\_SB_.PCI0.S28_) > > > [3.337408] shpchp :00:03.0: Requesting control of SHPC hotplug via > > > OSHP (\_SB_.PCI0) > > > [3.338710] shpchp :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 :00:03.0: Requesting control of SHPC hotplug via > > > OSHP (\_SB_.PCI0.S18_) > > > [1.704934] shpchp :00:03.0: Requesting control of SHPC hotplug via > > > OSHP (\_SB_.PCI0) > > > [1.705855] shpchp :00:03.0: Gained control of SHPC hotplug > > > (\_SB_.PCI0) > > > [1.707054] shpchp :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 >
Re: [v2 1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load
> > 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 :00:03.0: Requesting control of SHPC hotplug via
> >OSHP (\_SB_.PCI0.S28_)
> > [3.337408] shpchp :00:03.0: Requesting control of SHPC hotplug via
> >OSHP (\_SB_.PCI0)
> > [3.338710] shpchp :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 :00:03.0: Requesting control of SHPC hotplug via
> >OSHP (\_SB_.PCI0.S18_)
> > [1.704934] shpchp :00:03.0: Requesting control of SHPC hotplug via
> >OSHP (\_SB_.PCI0)
> > [1.705855] shpchp :00:03.0: Gained control of SHPC hotplug
> >(\_SB_.PCI0)
> > [1.707054] shpchp :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 :00:03.0: Requesting control of SHPC hotplug via OSHP
(\_SB_.PCI0.S18_)
[6.171962] shpchp :00:03.0: Requesting control of SHPC hotplug via OSHP
(\_SB_.PCI0)
[6.173556] shpchp :00:03.0: Gained control of SHPC hotplug (\_SB_.PCI0)
[6.175144] shpchp :00:03.0: HPC vendor_id 1b36 device_id 1 ss_vid 0
ss_did 0
[6.196153] shpchp :00:03.0: irq 24 for MSI/MSI-X
[6.197211] shpchp :00:03.0: pci_hp_register failed with error -16
[6.198272] shpchp :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.
Re: [v2 1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load
On Tue, 25 Jun 2024 11:52:24 +0800
Shiyuan Gao 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 :00:03.0: Requesting control of SHPC hotplug via OSHP
> (\_SB_.PCI0.S28_)
> [3.337408] shpchp :00:03.0: Requesting control of SHPC hotplug via OSHP
> (\_SB_.PCI0)
> [3.338710] shpchp :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 :00:03.0: Requesting control of SHPC hotplug via OSHP
> (\_SB_.PCI0.S18_)
> [1.704934] shpchp :00:03.0: Requesting control of SHPC hotplug via OSHP
> (\_SB_.PCI0)
> [1.705855] shpchp :00:03.0: Gained control of SHPC hotplug (\_SB_.PCI0)
> [1.707054] shpchp :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
> ---
> 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) {
