public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ni, Ray" <ray.ni@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Dong, Guo" <guo.dong@intel.com>,
	"Liu, Zhiguang" <zhiguang.liu@intel.com>
Cc: "Wang, Jian J" <jian.j.wang@intel.com>,
	"Wu, Hao A" <hao.a.wu@intel.com>,
	"Bi, Dandan" <dandan.bi@intel.com>,
	Liming Gao <gaoliming@byosoft.com.cn>,
	Andrew Fish <afish@apple.com>
Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob
Date: Wed, 24 Mar 2021 04:09:05 +0000	[thread overview]
Message-ID: <CO1PR11MB4930CBB9080F4C670C3A3F238C639@CO1PR11MB4930.namprd11.prod.outlook.com> (raw)
In-Reply-To: <ce6c5775-f161-d434-18c4-503646600e83@redhat.com>

> 
> (1) Currently, BlSupportDxe expects the ACPI content to come from
> "SYSTEM_TABLE_INFO.AcpiTableBase"
> [Include/Guid/SystemTableInfoGuid.h].
> That header file is at least *moderately* documented (it's better than
> nothing). Additionally, BlSupportDxe is a DXE-phase component.
> 
> The patch set removes the handling of
> "SYSTEM_TABLE_INFO.AcpiTableBase"
> from BlSupportDxe. That means that platforms currently relying on
> BlSupportDxe to expose the ACPI content will break (until they start
> producing the new HOB). I don't see the HOB (with this particular GUID)
> being produced in UefiPayloadPkg anywhere.

The concern is about PEI passing ACPI Table location through two kinds
of HOBs. It looks like a flaw in the design. I agree.

The HOB is produced by PEI phase, by some code that doesn't belong
to edk2 repo.

> 
> (2) The UefiPayloadEntry module ("This is the first module for UEFI
> payload") still relies on "SYSTEM_TABLE_INFO.AcpiTableBase", for parsing
> various pieces of information into the "AcpiBoardInfo" structure. So
> even if the HOB producer phase exposes the ACPI payload via a dedicated
> HOB, it will only create inconsistency between the information parsed by
> UefiPayloadEntry (from "SYSTEM_TABLE_INFO.AcpiTableBase") and the OS
> (which will the ACPI contents from the dedicated HOB).

I agree. At least the SYSTEM_TABLE_INFO.AcpiTableBase field should be removed
and the accordingly code that consumes ACPI Table in BlSupportDxe should
be updated to consume the new HOB.

> 
> (3) The new HOB's structure (regardless of GUID) is not declared in any
> MdeModulePkg header file, nor the "MdeModulePkg.dec" file. All the info
> we have is hidden in the source code:
> 
>   Rsdp = (EFI_ACPI_3_0_ROOT_SYSTEM_DESCRIPTION_POINTER*)
> (UINTN)(*((UINT64*)GET_GUID_HOB_DATA (GuidHob)));
> 
> If a platform's PEI phase actually inteded to produce this new HOB, it
> couldn't rely on a header file / DEC file.
> 
> This is actually a *step back* from the SystemTableInfoGuid declaration
> -- header file and DEC file -- that we currently have in UefiPayloadPkg.

gEfiAcpiTableGuid is defined in MdePkg/Include/Guid/Acpi.h.
The file header says the GUID is used for entry in EFI system table.
Now we reuse this GUID for HOB data.
I think it's ok to use a spec defined GUID for another implementation purpose.

I can create a file MdeModulePkg/Include/Guid/Acpi.h to define the HOB structure.
Do you think it's ok?

> 
> 
> So how can this be called "standardizing and modularizing"?
> 
> You need a new GUID, a new GUID HOB structure (declared in
> MdeModulePkg
> DEC and GUID header); you need to spell out the priority order between
> the HOB and "SYSTEM_TABLE_INFO.AcpiTableBase" for UefiPayloadPkg, and
> you need to update all driver in UefiPayloadPkg accordingly.

Again. I agree it's a flaw in the design. We should remove AcpiTableBase field.

> 
> 
> I will also not make a secret of my annoyance that, the first time Intel
> needs such a core extension for some platform feature, it immediately
> gets all approvals. Whereas, when we needed the exact same feature in
> OVMF, we struggled for months, if not *years*, to reliably split the
> ACPI content that OVMF downloaded from QEMU, into blobs that were
> suitable for the standard ACPI table protocol interfaces. For years I've
> been telling my colleagues that all this complexity in OVMF's ACPI
> platform driver is necessary because the EFI_ACPI_TABLE_PROTOCOL
> implementation in edk2 cannot simply accept a "root pointer", to the
> ACPI table "forest" that's already laid out in memory. Now I find it
> just a little bit too convenient that the first time Intel needs the
> same, we immediately call it "standardizing and modularizing" -- without
> as much as a header file describing the actual contents of the new GUID HOB.

I am not aware of the similar OVMF requirement.

The requirement here is to support different bootloaders that may already
create the essential ACPI table and DXE phase (payload) may use AcpiTable
protocol to install/update tables.

> 
> (Meanwhile we argue for months about actual, proven spec breakage in
> edk2, such as signaling ready to boot around recovery options or
> whatever. Standardization matters as long as *you* need it, huh?)

The definition of spec breakage to me is we cannot do anything that's
conflict with the spec. But we can do things that spec doesn't define.
Please correct if I am wrong.


  parent reply	other threads:[~2021-03-24  4:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-23  3:24 [Patch V2 1/2] MdeModulePkg/ACPI: Install ACPI table from HOB Zhiguang Liu
2021-03-23  3:24 ` [Patch V2 2/2] UefiPayloadPkg: Remove code that installs APCI Zhiguang Liu
2021-03-23  3:44   ` Ni, Ray
2021-03-23  5:19   ` Guo Dong
2021-03-23  3:24 ` [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob Zhiguang Liu
2021-03-23 12:40   ` [edk2-devel] " Laszlo Ersek
2021-03-23 15:45     ` Guo Dong
2021-03-23 16:12       ` Andrew Fish
2021-03-23 17:29         ` Guo Dong
2021-03-24  5:30         ` Ni, Ray
2021-03-23 16:48       ` Laszlo Ersek
2021-03-23 17:15         ` Guo Dong
2021-03-24  9:50           ` Laszlo Ersek
2021-03-24  4:09         ` Ni, Ray [this message]
2021-03-24 10:29           ` Laszlo Ersek
2021-03-23 23:52     ` Benjamin Doron
2021-03-24  9:53       ` Laszlo Ersek
2021-03-24 16:55         ` Benjamin Doron
2021-03-24 18:33           ` Laszlo Ersek
2021-03-25  1:10             ` Ni, Ray
2021-03-25  3:55               ` Andrew Fish
2021-03-25 17:35                 ` Laszlo Ersek
2021-03-25 17:33               ` Laszlo Ersek
2021-03-25  1:39             ` Benjamin Doron
2021-03-23  3:44 ` [Patch V2 1/2] MdeModulePkg/ACPI: Install ACPI table from HOB Ni, Ray

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-list 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=CO1PR11MB4930CBB9080F4C670C3A3F238C639@CO1PR11MB4930.namprd11.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /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