Re: Exporting discontiguous System Memory to EFI STUB

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 15 September 2016 at 10:01, Laszlo Ersek <lersek@redhat.com> wrote:
> On 09/15/16 10:45, Sakar Arora wrote:
>> Hi
>>
>> This is in aarch64 UEFI context.
>>
>> The efi stub code ignores any memory nodes in the device tree. It
>> only relies on the UEFI memory map for memory info.
>>
>> In such a scenario, how can one export discontiguous regions of
>> system memory to the efi stub? There seems to be only one way to
>> inform UEFI about system memory, via PcdSystemMemoryBase.
>>
>> Looking at the latest Arm Juno code, it seems like building a memory
>> resource descriptor hob, for the extra memory region, does the trick.
>> Would that be the best way to go?
>>
>> Suggestions please.
>
> There are two ways.
>
> First, in the PEI phase, you can produce memory resource descriptor HOBs
> that will describe system memory areas. When the DXE core starts, it
> will convert the suitable HOBs to EfiGcdMemoryTypeSystemMemory memory
> space. During DXE and BDS, boot/runtime code/data allocations will be
> satisfied from these. Then the UEFI memmap will reflect those
> allocations, and the system memory left unused, to the EFI stub.
>
> Second, you can add EfiGcdMemoryTypeSystemMemory memory space during and
> after the DXE phase, explicitly, using the DXE services. (IIRC, the PI
> spec says that memory space added this way may be picked by the UEFI
> memory allocation system immediately; IOW, it may immediately become
> available to the pool and page allocation boot serivces, to allocate
> from. IIRC, in edk2 this actually happens.) The rest is the same as
> above, wrt. the UEFI memmap.
>
> You can see an example for the second method under
> "ArmVirtPkg/HighMemDxe". I think it might be particularly close to your
> use case, as it practically translates the memory nodes found in QEMU's
> (copied) DTB to EfiGcdMemoryTypeSystemMemory memory space.
>
> (Ard, when do you plan to port this driver to FDT_CLIENT_PROTOCOL? :))
>

Any day now :-)

But seriously, I think this is orthogonal to the question, since I
don't expect that this platform uses DTB to describe the platform *to
UEFI*, and it would not run any of the runtime DT probing code.

So in this particular case, it is simply a matter of adding the
additional memory at any point during the execution of UEFI that is
convenient, by using one of the two methods you describe.

Thanks,
Ard.