public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, ard.biesheuvel@arm.com
Cc: Dandan Bi <dandan.bi@intel.com>,
	Liming Gao <gaoliming@byosoft.com.cn>,
	Jian J Wang <jian.j.wang@intel.com>,
	Hao A Wu <hao.a.wu@intel.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Leif Lindholm <leif@nuviainc.com>
Subject: Re: [edk2-devel] [PATCH 2/3] MdeModulePkg/AcpiTableDxe: use pool allocation for RSDT/XSDT if possible
Date: Mon, 19 Oct 2020 22:06:12 +0200	[thread overview]
Message-ID: <11f117f4-7c40-d9ce-8ffb-804f01ac9e00@redhat.com> (raw)
In-Reply-To: <20201016154923.21260-3-ard.biesheuvel@arm.com>

On 10/16/20 17:49, Ard Biesheuvel wrote:
> If no memory allocation limit is in effect for ACPI tables, prefer
> pool allocations over page allocations, to avoid wasting memory on
> systems where page based allocations are rounded up to 64 KB, such
> as AArch64.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
> ---
>  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 111 ++++++++++++--------
>  1 file changed, 65 insertions(+), 46 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> index b05e57e6584f..22f49a8489e7 100644
> --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
> @@ -355,28 +355,35 @@ ReallocateAcpiTableBuffer (
>                   NewMaxTableNumber * sizeof (UINT32);
>    }
>  
> -  //
> -  // Allocate memory in the lower 32 bit of address range for
> -  // compatibility with ACPI 1.0 OS.
> -  //
> -  // This is done because ACPI 1.0 pointers are 32 bit values.
> -  // ACPI 2.0 OS and all 64 bit OS must use the 64 bit ACPI table addresses.
> -  // There is no architectural reason these should be below 4GB, it is purely
> -  // for convenience of implementation that we force memory below 4GB.
> -  //
> -  PageAddress = 0xFFFFFFFF;
> -  Status = gBS->AllocatePages (
> -                  mAcpiTableAllocType,
> -                  EfiACPIReclaimMemory,
> -                  EFI_SIZE_TO_PAGES (TotalSize),
> -                  &PageAddress
> -                  );
> +  if (mAcpiTableAllocType != AllocateAnyPages) {
> +    //
> +    // Allocate memory in the lower 32 bit of address range for
> +    // compatibility with ACPI 1.0 OS.
> +    //
> +    // This is done because ACPI 1.0 pointers are 32 bit values.
> +    // ACPI 2.0 OS and all 64 bit OS must use the 64 bit ACPI table addresses.
> +    // There is no architectural reason these should be below 4GB, it is purely
> +    // for convenience of implementation that we force memory below 4GB.

Hmmm. I first thought that the last two lines of the commend should not
be re-instated. But I was wrong. Because supporting ACPI 1.0b causes us
to allocate even areas pointed-to by XSDT entries under 4GB.

> +    //
> +    PageAddress = 0xFFFFFFFF;
> +    Status = gBS->AllocatePages (
> +                    mAcpiTableAllocType,
> +                    EfiACPIReclaimMemory,
> +                    EFI_SIZE_TO_PAGES (TotalSize),
> +                    &PageAddress
> +                    );
> +    Pointer = (UINT8 *)(UINTN)PageAddress;

(1) Same comment as before; we shouldn't convert PageAddress to a
pointer unless the allocation succeeds.

> +  } else {
> +    Status = gBS->AllocatePool (
> +                    EfiACPIReclaimMemory,
> +                    TotalSize,
> +                    (VOID **)&Pointer);
> +  }
>  
>    if (EFI_ERROR (Status)) {
>      return EFI_OUT_OF_RESOURCES;
>    }
>  
> -  Pointer = (UINT8 *) (UINTN) PageAddress;
>    ZeroMem (Pointer, TotalSize);
>  
>    AcpiTableInstance->Rsdt1 = (EFI_ACPI_DESCRIPTION_HEADER *) Pointer;
> @@ -406,21 +413,26 @@ ReallocateAcpiTableBuffer (
>    }
>    CopyMem (AcpiTableInstance->Xsdt, TempPrivateData.Xsdt, (sizeof (EFI_ACPI_DESCRIPTION_HEADER) + mEfiAcpiMaxNumTables * sizeof (UINT64)));
>  
> -  //
> -  // Calculate orignal ACPI table buffer size
> -  //
> -  TotalSize = sizeof (EFI_ACPI_DESCRIPTION_HEADER) +         // for ACPI 2.0/3.0 XSDT
> -              mEfiAcpiMaxNumTables * sizeof (UINT64);
> +  if (mAcpiTableAllocType != AllocateAnyPages) {
> +    //
> +    // Calculate orignal ACPI table buffer size
> +    //
> +    TotalSize = sizeof (EFI_ACPI_DESCRIPTION_HEADER) +         // for ACPI 2.0/3.0 XSDT
> +                mEfiAcpiMaxNumTables * sizeof (UINT64);
>  
> -  if ((PcdGet32 (PcdAcpiExposedTableVersions) & EFI_ACPI_TABLE_VERSION_1_0B) != 0) {
> -    TotalSize += sizeof (EFI_ACPI_DESCRIPTION_HEADER) +         // for ACPI 1.0 RSDT
> -                 mEfiAcpiMaxNumTables * sizeof (UINT32) +
> -                 sizeof (EFI_ACPI_DESCRIPTION_HEADER) +         // for ACPI 2.0/3.0 RSDT
> -                 mEfiAcpiMaxNumTables * sizeof (UINT32);
> +    if ((PcdGet32 (PcdAcpiExposedTableVersions) & EFI_ACPI_TABLE_VERSION_1_0B) != 0) {
> +      TotalSize += sizeof (EFI_ACPI_DESCRIPTION_HEADER) +         // for ACPI 1.0 RSDT
> +                   mEfiAcpiMaxNumTables * sizeof (UINT32) +
> +                   sizeof (EFI_ACPI_DESCRIPTION_HEADER) +         // for ACPI 2.0/3.0 RSDT
> +                   mEfiAcpiMaxNumTables * sizeof (UINT32);
> +    }
> +
> +    gBS->FreePages ((EFI_PHYSICAL_ADDRESS)(UINTN)TempPrivateData.Rsdt1,
> +           EFI_SIZE_TO_PAGES (TotalSize));
> +  } else {
> +    gBS->FreePool (TempPrivateData.Rsdt1);
>    }
>  
> -  gBS->FreePages ((EFI_PHYSICAL_ADDRESS)(UINTN)TempPrivateData.Rsdt1, EFI_SIZE_TO_PAGES (TotalSize));
> -
>    //
>    // Update the Max ACPI table number
>    //
> @@ -1759,29 +1771,36 @@ AcpiTableAcpiTableConstructor (
>                   mEfiAcpiMaxNumTables * sizeof (UINT32);
>    }
>  
> -  //
> -  // Allocate memory in the lower 32 bit of address range for
> -  // compatibility with ACPI 1.0 OS.
> -  //
> -  // This is done because ACPI 1.0 pointers are 32 bit values.
> -  // ACPI 2.0 OS and all 64 bit OS must use the 64 bit ACPI table addresses.
> -  // There is no architectural reason these should be below 4GB, it is purely
> -  // for convenience of implementation that we force memory below 4GB.
> -  //
> -  PageAddress = 0xFFFFFFFF;
> -  Status = gBS->AllocatePages (
> -                  mAcpiTableAllocType,
> -                  EfiACPIReclaimMemory,
> -                  EFI_SIZE_TO_PAGES (TotalSize),
> -                  &PageAddress
> -                  );
> +  if (mAcpiTableAllocType != AllocateAnyPages) {
> +    //
> +    // Allocate memory in the lower 32 bit of address range for
> +    // compatibility with ACPI 1.0 OS.
> +    //
> +    // This is done because ACPI 1.0 pointers are 32 bit values.
> +    // ACPI 2.0 OS and all 64 bit OS must use the 64 bit ACPI table addresses.
> +    // There is no architectural reason these should be below 4GB, it is purely
> +    // for convenience of implementation that we force memory below 4GB.
> +    //
> +    PageAddress = 0xFFFFFFFF;
> +    Status = gBS->AllocatePages (
> +                    mAcpiTableAllocType,
> +                    EfiACPIReclaimMemory,
> +                    EFI_SIZE_TO_PAGES (TotalSize),
> +                    &PageAddress
> +                    );
> +    Pointer = (UINT8 *)(UINTN)PageAddress;

(2) Same as (1).

Looks reasonable otherwise.

Thanks
Laszlo


> +  } else {
> +    Status = gBS->AllocatePool (
> +                    EfiACPIReclaimMemory,
> +                    TotalSize,
> +                    (VOID **)&Pointer);
> +  }
>  
>    if (EFI_ERROR (Status)) {
>      gBS->FreePages ((EFI_PHYSICAL_ADDRESS)(UINTN)AcpiTableInstance->Rsdp1, EFI_SIZE_TO_PAGES (RsdpTableSize));
>      return EFI_OUT_OF_RESOURCES;
>    }
>  
> -  Pointer = (UINT8 *) (UINTN) PageAddress;
>    ZeroMem (Pointer, TotalSize);
>  
>    AcpiTableInstance->Rsdt1 = (EFI_ACPI_DESCRIPTION_HEADER *) Pointer;
> 


  reply	other threads:[~2020-10-19 20:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-16 15:49 [PATCH 0/3] MdeModulePkg: use pool allocations for ACPI tables Ard Biesheuvel
2020-10-16 15:49 ` [PATCH 1/3] MdeModulePkg/AcpiTableDxe: use pool allocations when possible Ard Biesheuvel
2020-10-19 19:47   ` [edk2-devel] " Laszlo Ersek
2020-10-22  2:01     ` 回复: " gaoliming
2020-10-22 12:55       ` Ard Biesheuvel
2020-10-26  1:35         ` 回复: " gaoliming
2020-10-26  6:25           ` Laszlo Ersek
2020-10-26  7:42             ` Ard Biesheuvel
2020-10-27  8:45               ` 回复: " gaoliming
2020-10-27  9:05                 ` Ard Biesheuvel
2020-10-27 11:07               ` Laszlo Ersek
2020-10-16 15:49 ` [PATCH 2/3] MdeModulePkg/AcpiTableDxe: use pool allocation for RSDT/XSDT if possible Ard Biesheuvel
2020-10-19 20:06   ` Laszlo Ersek [this message]
2020-10-19 20:11     ` [edk2-devel] " Laszlo Ersek
2020-10-16 15:49 ` [PATCH 3/3] MdeModulePkg/AcpiTableDxe: use pool allocation for RSDP " Ard Biesheuvel
2020-10-19 20:13   ` [edk2-devel] " Laszlo Ersek
2020-10-19  1:28 ` FW: [PATCH 0/3] MdeModulePkg: use pool allocations for ACPI tables Wu, Hao A
2020-10-19  1:59   ` Wu, Hao A

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=11f117f4-7c40-d9ce-8ffb-804f01ac9e00@redhat.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