From: Igor Mammedov <imammedo@redhat.com>
To: "Gao,Shiyuan" <gaoshiyuan@baidu.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"mst@redhat.com" <mst@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [v2 1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load
Date: Mon, 1 Jul 2024 10:40:00 +0200 [thread overview]
Message-ID: <20240701104000.52df4854@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <6d033738d79d4b9a83fe216679f8e587@baidu.com>
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.
>
next prev parent reply other threads:[~2024-07-01 8:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 3:52 [v2 1/1] hw/i386/acpi-build: add OSHP method support for SHPC driver load Shiyuan Gao via
2024-06-27 13:45 ` Igor Mammedov
2024-06-28 3:04 ` Gao,Shiyuan via
2024-06-28 3:12 ` Gao,Shiyuan via
2024-07-01 8:40 ` Igor Mammedov [this message]
2024-07-01 9:39 ` Gao,Shiyuan via
2024-07-01 13:19 ` Gerd Hoffmann
2024-07-01 14:27 ` Gao,Shiyuan via
2024-07-02 8:26 ` Igor Mammedov
2024-07-02 9:09 ` Gao,Shiyuan via
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240701104000.52df4854@imammedo.users.ipa.redhat.com \
--to=imammedo@redhat.com \
--cc=gaoshiyuan@baidu.com \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).