From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob To: Laszlo Ersek ,devel@edk2.groups.io From: "Benjamin Doron" X-Originating-Location: Thornhill, Ontario, CA (24.52.200.135) X-Originating-Platform: Linux Firefox 86 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Wed, 24 Mar 2021 18:39:01 -0700 References: <2e602df8-b1fc-193b-f61a-86802ace9108@redhat.com> In-Reply-To: <2e602df8-b1fc-193b-f61a-86802ace9108@redhat.com> Message-ID: <14713.1616636341486510048@groups.io> Content-Type: multipart/alternative; boundary="6c42s2eU8GGDzG3uFCry" --6c42s2eU8GGDzG3uFCry Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 24, 2021 at 02:33 PM, Laszlo Ersek wrote: >=20 >=20 >>=20 >>>=20 >>>> Hi all, >>>> Would it be acceptable/feasible for AcpiTableDxe or AcpiPlatformDxe (= in >>>> MdeModulePkg) to use `EfiGetSystemConfigurationTable` to get the RSDP >>>> and then install the tables? It's a solution that uses the regular >>>> UefiLib, so it avoids platform-specific quirks (and as I see it, if R= SDP >>>> is in the configuration table, we probably always want those tables). >>>=20 >>> I'm sorry, I don't understand how this would help. >>=20 >> As I understand it, the issue is that this patchset changes MdeModulePk= g >> to do platform-specific parsing. >>=20 >> Perhaps it would be an acceptable solution for platforms to retrieve th= e >> tables, then add >> RSDP/them to the configuration table to be installed by >> AcpiTableDxe/AcpiPlatformDxe. >> This allows MdeModulePkg to abstract away the parsing, only installing >> tables >> available to it. >=20 > But this is already the best approach, and already what's happening -- > when you call EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() from the > platform's AcpiPlatformDxe, that's *how* you tell AcpiTableDxe in > MdeModulePkg to pick up the table and hook it into the RSDT / XSDT / > wherever, and also to manage RSD PTR as a UEFI configuration table. >=20 > Are you (more or less) proposing a new EFI_ACPI_TABLE_PROTOCOL member > function for taking a forest of ACPI tables, passed in by RSD PTR? Yes. I thought the implementation of AcpiPlatformDxe in MdeModulePkg could take= it, so it will install ACPI tables from flash or from memory. Regarding UefiPayloadPkg: gEfiAcpiTableGuid is not a HOB. It's an entry in gUefiSystemTableInfoGuid (which is a HOB) that was installed in the config= table. Therefore, retrieving its GUID as a HOB in AcpiTableDxe fails. To make this patchset work in UefiPayloadPkg (actually a fork), I have to = add AcpiTableDxe to its FDF, drop patch 2/2 and make `InstallAcpiTableFromHob` do `Status =3D EfiGetSystemConfigurationTable (&gEfiAcpiTableGuid, (VOID **) = &Rsdp);`. Then, this patchset works: "acpiview" shell command shows tables from QEMU= + coreboot, as well as a BGRT. --6c42s2eU8GGDzG3uFCry Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 24, 2021 at 02:33 PM, Laszlo Ersek wrote:
Hi all,
Would it be acceptable/feasible for AcpiTableDxe = or AcpiPlatformDxe (in
MdeModulePkg) to use `EfiGetSystemConfiguration= Table` to get the RSDP
and then install the tables? It's a solution th= at uses the regular
UefiLib, so it avoids platform-specific quirks (an= d as I see it, if RSDP
is in the configuration table, we probably alwa= ys want those tables).
I'm sorry, I don't understand how this would help.
As I understand it, the issue is that this patchset changes MdeModulePkg t= o do platform-specific parsing.

Perhaps it would be an acceptabl= e solution for platforms to retrieve the tables, then add
RSDP/them to= the configuration table to be installed by AcpiTableDxe/AcpiPlatformDxe.This allows MdeModulePkg to abstract away the parsing, only installing = tables
available to it.
But this is already the best approach, and already what's happening --
when you call EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() from the
pl= atform's AcpiPlatformDxe, that's *how* you tell AcpiTableDxe in
MdeMod= ulePkg to pick up the table and hook it into the RSDT / XSDT /
whereve= r, and also to manage RSD PTR as a UEFI configuration table.

Are= you (more or less) proposing a new EFI_ACPI_TABLE_PROTOCOL member
fun= ction for taking a forest of ACPI tables, passed in by RSD PTR? Yes.
I thought the implementation of AcpiPlatformDxe in MdeModulePkg = could take it, so it will install
ACPI tables from flash or from memor= y.

Regarding UefiPayloadPkg: gEfiAcpiTableGuid is not a HOB. It'= s an entry in
gUefiSystemTableInfoGuid (which is a HOB) that was insta= lled in the config table. Therefore,
retrieving its GUID as a HOB in A= cpiTableDxe fails.

To make this patchset work in UefiPayloadPkg = (actually a fork), I have to add AcpiTableDxe to its
FDF, drop patch 2= /2 and make `InstallAcpiTableFromHob` do
`Status =3D EfiGetSystemConfi= gurationTable (&gEfiAcpiTableGuid, (VOID **) &Rsdp);`.
Then, t= his patchset works: "acpiview" shell command shows tables from QEMU + coreb= oot, as well
as a BGRT. --6c42s2eU8GGDzG3uFCry--