From: "Kinney, Michael D" <michael.d.kinney@intel.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
"Kinney, Michael D" <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>,
Leif Lindholm <leif.lindholm@linaro.org>,
"Gao, Liming" <liming.gao@intel.com>,
"Zeng, Star" <star.zeng@intel.com>,
"Dong, Eric" <eric.dong@intel.com>,
"Bi, Dandan" <dandan.bi@intel.com>
Subject: Re: [PATCH 3/6] MdePkg/UefiLib: introduce EfiAllocatePeiAccessiblePages routine
Date: Tue, 22 May 2018 17:40:03 +0000 [thread overview]
Message-ID: <E92EE9817A31E24EB0585FDF735412F5B8A37639@ORSMSX113.amr.corp.intel.com> (raw)
In-Reply-To: <20180522140850.30369-4-ard.biesheuvel@linaro.org>
Ard,
The corner case that does not work with this
approach is when X64 DXE is combined with an
X64 PEI. OVMF uses this and other platforms
could choose to use X64 PEI phase.
The other mismatch here is adding some PI Spec
Concepts (e.g. PEI phase) to a UEFI library.
Maybe DxeServicesLib would be a better place
to put this type of API.
One clue we have about the memory usage in the
PEI phase is from the EFI_HOB_HANDOFF_INFO_TABLE
HOB.
///
/// The highest address location of memory that is allocated for use by the HOB producer
/// phase. This address must be 4-KB aligned to meet page restrictions of UEFI.
///
EFI_PHYSICAL_ADDRESS EfiMemoryTop;
///
/// The highest address location of free memory that is currently available
/// for use by the HOB producer phase.
///
EFI_PHYSICAL_ADDRESS EfiFreeMemoryTop;
So maybe we could have an X64 specific implementation
of this new API that checks one of these HOB fields.
If they are below 4GB, then allocate memory below
4GB. If one is above 4GB, then no restrictions.
All other archs allocate with no restrictions.
Now this approach will still allocate below 4GB for
X64 PEI if the this HOB contains addressed below 4GB,
but that would match the memory usage for that
X64 PEI implementation.
Best regards,
Mike
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Tuesday, May 22, 2018 7:09 AM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Laszlo
> Ersek <lersek@redhat.com>; Leif Lindholm
> <leif.lindholm@linaro.org>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Gao, Liming
> <liming.gao@intel.com>; Zeng, Star
> <star.zeng@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Bi, Dandan <dandan.bi@intel.com>
> Subject: [PATCH 3/6] MdePkg/UefiLib: introduce
> EfiAllocatePeiAccessiblePages routine
>
> Add a routine to UefiLib that abstracts the allocation
> of memory that
> should be accessible by PEI after a warm reboot. We will
> use it to
> replace open coded implementations that limit the
> address to < 4 GB,
> which may not be possible on non-Intel systems that have
> no 32-bit
> addressable memory at all.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> <ard.biesheuvel@linaro.org>
> ---
> MdePkg/Include/Library/UefiLib.h | 23 ++++++++++
> MdePkg/Library/UefiLib/UefiLib.c | 48
> ++++++++++++++++++++
> 2 files changed, 71 insertions(+)
>
> diff --git a/MdePkg/Include/Library/UefiLib.h
> b/MdePkg/Include/Library/UefiLib.h
> index 256498e3fd8d..8fa077af41e0 100644
> --- a/MdePkg/Include/Library/UefiLib.h
> +++ b/MdePkg/Include/Library/UefiLib.h
> @@ -1520,4 +1520,27 @@ EfiLocateProtocolBuffer (
> OUT UINTN *NoProtocols,
> OUT VOID ***Buffer
> );
> +
> +/**
> + Allocates one or more 4KB pages of a given type from
> a memory region that is
> + accessible to PEI.
> +
> + Allocates the number of 4KB pages of type
> 'MemoryType' and returns a
> + pointer to the allocated buffer. The buffer returned
> is aligned on a 4KB
> + boundary. If Pages is 0, then NULL is returned. If
> there is not enough
> + memory remaining to satisfy the request, then NULL is
> returned.
> +
> + @param[in] MemoryType The memory type to
> allocate
> + @param[in] Pages The number of 4 KB
> pages to allocate.
> +
> + @return A pointer to the allocated buffer or NULL if
> allocation fails.
> +
> +**/
> +VOID *
> +EFIAPI
> +EfiAllocatePeiAccessiblePages (
> + IN EFI_MEMORY_TYPE MemoryType,
> + IN UINTN Pages
> + );
> +
> #endif
> diff --git a/MdePkg/Library/UefiLib/UefiLib.c
> b/MdePkg/Library/UefiLib/UefiLib.c
> index ba449a1c34ce..3a9d75149dd7 100644
> --- a/MdePkg/Library/UefiLib/UefiLib.c
> +++ b/MdePkg/Library/UefiLib/UefiLib.c
> @@ -1715,3 +1715,51 @@ EfiLocateProtocolBuffer (
>
> return EFI_SUCCESS;
> }
> +
> +/**
> + Allocates one or more 4KB pages of a given type from
> a memory region that is
> + accessible to PEI.
> +
> + Allocates the number of 4KB pages of type
> 'MemoryType' and returns a
> + pointer to the allocated buffer. The buffer returned
> is aligned on a 4KB
> + boundary. If Pages is 0, then NULL is returned. If
> there is not enough
> + memory remaining to satisfy the request, then NULL is
> returned.
> +
> + @param[in] MemoryType The memory type to
> allocate
> + @param[in] Pages The number of 4 KB
> pages to allocate.
> +
> + @return A pointer to the allocated buffer or NULL if
> allocation fails.
> +
> +**/
> +VOID *
> +EFIAPI
> +EfiAllocatePeiAccessiblePages (
> + IN EFI_MEMORY_TYPE MemoryType,
> + IN UINTN Pages
> + )
> +{
> + EFI_STATUS Status;
> + EFI_PHYSICAL_ADDRESS Memory;
> + EFI_ALLOCATE_TYPE AllocType;
> +
> + if (Pages == 0) {
> + return NULL;
> + }
> +
> +#ifdef MDE_CPU_X64
> + //
> + // On X64 systems, a X64 build of DXE may be combined
> with a 32-bit build of
> + // PEI, and so we need to allocate below 4 GB to
> ensure that the allocation
> + // is accessible by PEI.
> + //
> + AllocType = AllocateMaxAddress;
> + Memory = MAX_UINT32;
> +#else
> + AllocType = AllocateAnyPages;
> +#endif
> + Status = gBS->AllocatePages (AllocType, MemoryType,
> Pages, &Memory);
> + if (EFI_ERROR (Status)) {
> + return NULL;
> + }
> + return (VOID *)(UINTN)Memory;
> +}
> --
> 2.17.0
next prev parent reply other threads:[~2018-05-22 17:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 14:08 [PATCH 0/6] Abstract allocation of PEI accessible memory Ard Biesheuvel
2018-05-22 14:08 ` [PATCH 1/6] OvmfPkg/PlatformBootManagerLib: add missing report status code call Ard Biesheuvel
2018-05-22 18:58 ` Laszlo Ersek
2018-05-22 14:08 ` [PATCH 2/6] ArmVirtPkg/PlatformBootManagerLib: " Ard Biesheuvel
2018-05-22 18:58 ` Laszlo Ersek
2018-05-22 14:08 ` [PATCH 3/6] MdePkg/UefiLib: introduce EfiAllocatePeiAccessiblePages routine Ard Biesheuvel
2018-05-22 17:40 ` Kinney, Michael D [this message]
2018-05-22 17:47 ` Ard Biesheuvel
2018-05-22 19:11 ` Laszlo Ersek
2018-05-23 2:02 ` Zeng, Star
2018-05-23 1:59 ` Zeng, Star
2018-05-22 14:08 ` [PATCH 4/6] IntelFrameworkPkg/FrameworkUefiLib: add " Ard Biesheuvel
2018-05-22 14:08 ` [PATCH 5/6] MdeModulePkg/DxeCorePerformanceLib: use EfiAllocatePeiAccessiblePages Ard Biesheuvel
2018-05-22 14:08 ` [PATCH 6/6] MdeModulePkg/FirmwarePerformanceDataTableDxe: " Ard Biesheuvel
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=E92EE9817A31E24EB0585FDF735412F5B8A37639@ORSMSX113.amr.corp.intel.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