From: Laszlo Ersek <lersek@redhat.com>
To: Eric Dong <eric.dong@intel.com>, edk2-devel@lists.01.org
Cc: "Marvin Häuser" <Marvin.Haeuser@outlook.com>,
"Fan Jeff" <vanjeff_919@hotmail.com>,
"Ruiyu Ni" <ruiyu.ni@intel.com>
Subject: Re: [Patch v3 3/5] UefiCpuPkg/CpuS3DataDxe: Change Memory Type and address limitation.
Date: Fri, 10 Aug 2018 18:12:54 +0200 [thread overview]
Message-ID: <ebcce00d-3797-b447-92e9-1535d13f7b1a@redhat.com> (raw)
In-Reply-To: <20180810041909.12776-4-eric.dong@intel.com>
On 08/10/18 06:19, Eric Dong wrote:
> Because CpuS3Data memory will be copy to smram at SmmReadyToLock point,
> the memory type no need to be ACPI NVS type, also the address not
> limit to below 4G.
>
> This change remove the limit of ACPI NVS memory type and below 4G.
>
> Pass OS boot and resume from S3 test.
>
> Cc: Marvin Häuser <Marvin.Haeuser@outlook.com>
> Cc: Fan Jeff <vanjeff_919@hotmail.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong <eric.dong@intel.com>
> ---
> UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c | 43 +++++++++++++++++++++++++++++++------
> 1 file changed, 36 insertions(+), 7 deletions(-)
>
> diff --git a/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c b/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> index dccb406b8d..5b99a6e759 100644
> --- a/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> +++ b/UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c
> @@ -81,6 +81,38 @@ AllocateAcpiNvsMemoryBelow4G (
> return Buffer;
> }
>
> +/**
> + Allocate EfiBootService memory.
> +
> + @param[in] Size Size of memory to allocate.
> +
> + @return Allocated address for output.
> +
> +**/
> +VOID *
> +AllocateBootServiceMemory (
> + IN UINTN Size
> + )
> +{
> + EFI_PHYSICAL_ADDRESS Address;
> + EFI_STATUS Status;
> + VOID *Buffer;
> +
> + Status = gBS->AllocatePages (
> + AllocateAnyPages,
> + EfiBootServicesData,
> + EFI_SIZE_TO_PAGES (Size),
> + &Address
> + );
> + if (EFI_ERROR (Status)) {
> + return NULL;
> + }
> +
> + Buffer = (VOID *)(UINTN)Address;
> + ZeroMem (Buffer, Size);
> +
> + return Buffer;
> +}
(1) If I remember correctly, we discussed AllocateZeroPages() for this.
Why did you decide against it?
CpuS3DataDxe is a DXE_DRIVER, and the matching MemoryAllocationLib
instance would allocate Boot Services Data type memory.
> /**
> Callback function executed when the EndOfDxe event group is signaled.
>
> @@ -171,10 +203,7 @@ CpuS3DataInitialize (
> //
> OldAcpiCpuData = (ACPI_CPU_DATA *) (UINTN) PcdGet64 (PcdCpuS3DataAddress);
>
> - //
> - // Allocate ACPI NVS memory below 4G memory for use on ACPI S3 resume.
> - //
> - AcpiCpuDataEx = AllocateAcpiNvsMemoryBelow4G (sizeof (ACPI_CPU_DATA_EX));
> + AcpiCpuDataEx = AllocateBootServiceMemory (sizeof (ACPI_CPU_DATA_EX));
> ASSERT (AcpiCpuDataEx != NULL);
> AcpiCpuData = &AcpiCpuDataEx->AcpiCpuData;
>
> @@ -223,11 +252,11 @@ CpuS3DataInitialize (
> AsmReadIdtr (&AcpiCpuDataEx->IdtrProfile);
>
(2) In the previous patch, we lifted the 4GB limitation on the stack
address (while preserving the memory type restriction as AcpiNVS).
However, you continue to allocate the stack with
AllocateAcpiNvsMemoryBelow4G().
I don't think that's consistent with the purpose of this patch set, or
with the documentation change in the previous patch. We should allocate
the stack as AcpiNVS without address limitation.
And then we can remove the AllocateAcpiNvsMemoryBelow4G() function
altogether.
> //
> - // Allocate GDT and IDT in ACPI NVS and copy current GDT and IDT contents
> + // Allocate GDT and IDT and copy current GDT and IDT contents
> //
> GdtSize = AcpiCpuDataEx->GdtrProfile.Limit + 1;
> IdtSize = AcpiCpuDataEx->IdtrProfile.Limit + 1;
> - Gdt = AllocateAcpiNvsMemoryBelow4G (GdtSize + IdtSize);
> + Gdt = AllocateBootServiceMemory (GdtSize + IdtSize);
> ASSERT (Gdt != NULL);
> Idt = (VOID *)((UINTN)Gdt + GdtSize);
> CopyMem (Gdt, (VOID *)AcpiCpuDataEx->GdtrProfile.Base, GdtSize);
> @@ -243,7 +272,7 @@ CpuS3DataInitialize (
> // Allocate buffer for empty RegisterTable and PreSmmInitRegisterTable for all CPUs
> //
> TableSize = 2 * NumberOfCpus * sizeof (CPU_REGISTER_TABLE);
> - RegisterTable = (CPU_REGISTER_TABLE *)AllocateAcpiNvsMemoryBelow4G (TableSize);
> + RegisterTable = (CPU_REGISTER_TABLE *)AllocateBootServiceMemory (TableSize);
> ASSERT (RegisterTable != NULL);
>
> for (Index = 0; Index < NumberOfCpus; Index++) {
>
Thanks,
Laszlo
next prev parent reply other threads:[~2018-08-10 16:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-10 4:19 [Patch v3 0/5] Change CpuS3Data memory type and address limitation Eric Dong
2018-08-10 4:19 ` [Patch v3 1/5] UefiCpuPkg/PiSmmCpuDxeSmm: Use GDT/IDT saved in Smram Eric Dong
2018-08-10 15:40 ` Laszlo Ersek
2018-08-13 1:54 ` Dong, Eric
2018-08-14 12:51 ` Laszlo Ersek
2018-08-13 5:42 ` Ni, Ruiyu
2018-08-10 4:19 ` [Patch v3 2/5] UefiCpuPkg/AcpiCpuData.h: Remove AcpiNVS and Below 4G limitation Eric Dong
2018-08-10 15:58 ` Laszlo Ersek
2018-08-13 5:42 ` Ni, Ruiyu
2018-08-10 4:19 ` [Patch v3 3/5] UefiCpuPkg/CpuS3DataDxe: Change Memory Type and address limitation Eric Dong
2018-08-10 16:12 ` Laszlo Ersek [this message]
2018-08-10 16:15 ` Laszlo Ersek
2018-08-13 1:50 ` Dong, Eric
2018-08-13 5:38 ` Ni, Ruiyu
2018-08-13 5:52 ` Ni, Ruiyu
2018-08-14 12:49 ` Laszlo Ersek
2018-08-10 4:19 ` [Patch v3 4/5] UefiCpuPkg/CpuS3DataDxe: Remove below 4G limitation Eric Dong
2018-08-10 16:22 ` Laszlo Ersek
2018-08-13 5:41 ` Ni, Ruiyu
2018-08-10 4:19 ` [Patch v3 5/5] UefiCpuPkg/RegisterCpuFeaturesLib: Combine implementation Eric Dong
2018-08-10 16:34 ` Laszlo Ersek
2018-08-13 5:41 ` Ni, Ruiyu
2018-08-10 16:39 ` [Patch v3 0/5] Change CpuS3Data memory type and address limitation Laszlo Ersek
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=ebcce00d-3797-b447-92e9-1535d13f7b1a@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