From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
qemu-devel@nongnu.org, Igor Mammedov <imammedo@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>,
Laszlo Ersek <lersek@redhat.com>,
vit9696 <vit9696@protonmail.com>
Subject: Re: [PATCH 1/2] i386/acpi: fix inconsistent QEMU/OVMF device paths
Date: Thu, 30 Jul 2020 15:35:20 -0400 [thread overview]
Message-ID: <20200730153447-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <e1759ee7-b167-d69e-99f9-e824e9e3e0b8@redhat.com>
On Thu, Jul 30, 2020 at 06:11:17PM +0200, Philippe Mathieu-Daudé wrote:
> On 7/30/20 5:58 PM, Michael S. Tsirkin wrote:
> > macOS uses ACPI UIDs to build the DevicePath for NVRAM boot options,
> > while OVMF firmware gets them via an internal channel through QEMU.
> > Due to a bug in QEMU ACPI currently UEFI firmware and ACPI have
> > different values, and this makes the underlying operating system
> > unable to report its boot option.
> >
> > The particular node in question is the primary PciRoot (PCI0 in ACPI),
> > which for some reason gets assigned 1 in ACPI UID and 0 in the
> > DevicePath. This is due to the _UID assigned to it by build_dsdt in
> > hw/i386/acpi-build.c Which does not correspond to the primary PCI
> > identifier given by pcibus_num in hw/pci/pci.c
> >
> > Reference with the device paths, OVMF startup logs, and ACPI table
> > dumps (SysReport):
> > https://github.com/acidanthera/bugtracker/issues/1050
> >
> > In UEFI v2.8, section "10.4.2 Rules with ACPI _HID and _UID" ends with
> > the paragraph,
> >
> > Root PCI bridges will use the plug and play ID of PNP0A03, This will
> > be stored in the ACPI Device Path _HID field, or in the Expanded
> > ACPI Device Path _CID field to match the ACPI name space. The _UID
> > in the ACPI Device Path structure must match the _UID in the ACPI
> > name space.
> >
> > (See especially the last sentence.)
> >
> > Considering *extra* root bridges / root buses (with bus number > 0),
> > QEMU's ACPI generator actually does the right thing; since QEMU commit
> > c96d9286a6d7 ("i386/acpi-build: more traditional _UID and _HID for PXB
> > root buses", 2015-06-11).
> >
> > However, the _UID values for root bridge zero (on both i440fx and q35)
> > have always been "wrong" (from UEFI perspective), going back in QEMU to
> > commit 74523b850189 ("i386: add ACPI table files from seabios",
> > 2013-10-14).
> >
> > Even in SeaBIOS, these _UID values have always been 1; see commit
> > a4d357638c57 ("Port rombios32 code from bochs-bios.", 2008-03-08) for
> > i440fx, and commit ecbe3fd61511 ("seabios: q35: add dsdt", 2012-12-01)
> > for q35.
> >
> > Suggested-by: Laszlo Ersek <lersek@redhat.com>
> > Tested-by: vit9696 <vit9696@protonmail.com>
>
> Vitaly uses his full name on EDK2 mailing list, so I don't think he'll
> have a problem to use it in QEMU too:
> Tested-by: Vitaly Cheptsov <vit9696@protonmail.com>
>
> From:
> https://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line
> "Please use your real name to sign a patch (not an alias or acronym)."
Right. Tested-by is different though, I don't think we have
a problem with anonymous testing.
Anyway, updated.
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > hw/i386/acpi-build.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> > index b7bcbbbb2a..7a5a8b3521 100644
> > --- a/hw/i386/acpi-build.c
> > +++ b/hw/i386/acpi-build.c
> > @@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> > dev = aml_device("PCI0");
> > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03")));
> > aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > - aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > + aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> > aml_append(sb_scope, dev);
> > aml_append(dsdt, sb_scope);
> >
> > @@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> > aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08")));
> > aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03")));
> > aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
> > - aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> > + aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> > aml_append(dev, build_q35_osc_method());
> > aml_append(sb_scope, dev);
> > aml_append(dsdt, sb_scope);
> >
next prev parent reply other threads:[~2020-07-30 19:36 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-30 15:58 [PATCH 1/2] i386/acpi: fix inconsistent QEMU/OVMF device paths Michael S. Tsirkin
2020-07-30 15:58 ` [PATCH 2/2] arm/acpi: fix an out of spec _UID for PCI root Michael S. Tsirkin
2020-07-30 15:58 ` Michael S. Tsirkin
2020-07-30 16:12 ` Philippe Mathieu-Daudé
2020-07-30 16:12 ` Philippe Mathieu-Daudé
2020-07-30 19:35 ` Laszlo Ersek
2020-07-30 19:35 ` Laszlo Ersek
2020-07-30 20:33 ` Peter Maydell
2020-07-30 20:33 ` Peter Maydell
2020-07-31 9:31 ` Igor Mammedov
2020-07-30 16:11 ` [PATCH 1/2] i386/acpi: fix inconsistent QEMU/OVMF device paths Philippe Mathieu-Daudé
2020-07-30 19:35 ` Michael S. Tsirkin [this message]
2020-07-31 2:55 ` vit9696 via
2020-07-30 19:34 ` Laszlo Ersek
2020-07-31 9:30 ` Igor Mammedov
2021-02-27 19:41 ` Thomas Lamprecht
2021-02-28 9:11 ` vit9696
2021-02-28 10:43 ` Thomas Lamprecht
2021-02-28 20:45 ` Michael S. Tsirkin
[not found] ` <x3i3TiibtrC1qTDQUKxuOA_9qvmInzVwv6RrvzzSCSj-S21gLypbbZgEbYvJSGMxC1r8RaDrnHGgRbDI7vfpA_XuDINdZej9yKCW3_Sc4YM=@protonmail.com>
2021-02-28 21:37 ` Michael S. Tsirkin
2021-02-28 20:43 ` Michael S. Tsirkin
2021-03-01 7:12 ` Thomas Lamprecht
2021-03-01 7:20 ` Michael S. Tsirkin
2021-03-01 7:45 ` Thomas Lamprecht
2021-03-01 14:20 ` Igor Mammedov
2021-03-01 14:27 ` Thomas Lamprecht
2021-03-01 20:16 ` Igor Mammedov
2021-03-01 15:31 ` Michael S. Tsirkin
2021-03-01 13:28 ` Igor Mammedov
2021-03-01 16:14 ` Michael S. Tsirkin
2021-03-01 16:28 ` Laszlo Ersek
2021-03-01 19:08 ` Igor Mammedov
2021-03-01 20:06 ` vit9696
2021-03-02 8:40 ` Laszlo Ersek
-- strict thread matches above, loose matches on Subject: below --
2023-04-18 9:06 zhangying (AZ) via
2023-04-19 2:48 zhangying (AZ) via
2023-04-20 14:54 ` Igor Mammedov
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=20200730153447-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=lersek@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=vit9696@protonmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.