Re: Exporting discontiguous System Memory to EFI STUB

[Laszlo Ersek <lersek@redhat.com>]

On 09/21/16 13:20, Ard Biesheuvel wrote:
> On 21 September 2016 at 12:17, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 09/21/16 11:10, Bhupesh Sharma wrote:
>>> Thanks Ard, Laszlo.
>>>
>>> See replies in-line:
>>>
>>>> From: Ard Biesheuvel
>>>> Sent: Thursday, September 15, 2016 5:01 PM
>>>>
>>>> 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.
>>>>
>>>
>>> Yes, this platform, which has been extensively discussion on Linux mailing-lists
>>> as well for discontiguous memory regions and their support in Linux (see [1]),
>>> doesn't use DTB to describe the platform *to UEFI*.
>>>
>>> However I have one generic question. At the moment we seem to use the PcdSystemMemoryBase
>>> and PcdSystemMemorySize PCDs to convey to the PEI and DXE phases about the UEFI system
>>> memory limits.
>>
>> No, that's incorrect. These PCDs don't capture the full picture about
>> the "UEFI system memory limits". They just describe one initial memory
>> range; the one that will serve as the permanent PEI RAM. (In the PEI
>> phase, one of the PEIMs discovers and installs the "permanent PEI RAM",
>> which is one contiguous range, to be used by the rest of the PEI phase.
>> A bit later, the PEI core, the PEIMs, the HOBs etc (IIRC) are migrated
>> from the temporary PEI RAM to this "installed" permanent PEI RAM.)
>>
>> However, starting with the DXE phase, disjoint ranges of RAM are
>> supported; they can be installed by either using the appropriate DXE
>> services within DXE, or by producing appropriate HOBs still in PEI.
>>
>>
>>>
>>> How can we represent two discontiguous DDR regions in UEFI and make
>>> the EDK2 code base use both - to create MMU mappings from?
>>
>> As I said, by producing the right HOBs in PEI or by calling the right
>> DXE services in DXE. The actual range locations (= the fields of the
>> HOBs or the arguments to the DXE services) depend on your platform.
>>
>> Regarding the MMU: I don't know. I had always believed that the DXE
>> services should cover the MMU setup transparently, when new system
>> memory ranges are added -- as long as they exist within the address
>> space pre-announced by the CPU HOB --, but I do recall from another
>> thread on the list that this wasn't the case on ARM. I don't know why.
>>
> 
> I recently fixed a problem in the MMU code where the maximum size of
> the VA range which is programmed into the MMU registers was based on
> the initial memory size, and adding memory (or MMIO) ranges later
> would cause problems.
> 
> WIth the latest EDK2, adding memory may be done at any time, and will
> be reflected in the 1:1 mapping in the MMU

Perfect, thank you!
Laszlo