Exporting discontiguous System Memory to EFI STUB

Exporting discontiguous System Memory to EFI STUB

[Sakar Arora]

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.

Thanks,
Sakar

Re: Exporting discontiguous System Memory to EFI STUB

[Laszlo Ersek]

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? :))

Thanks
Laszlo

Re: Exporting discontiguous System Memory to EFI STUB

[Ard Biesheuvel]

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.

Re: Exporting discontiguous System Memory to EFI STUB

[Bhupesh Sharma]

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. 

How can we represent two discontiguous DDR regions in UEFI and make
the EDK2 code base use both - to create MMU mappings from?

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/435607.html

Regards,
Bhupesh

Re: Exporting discontiguous System Memory to EFI STUB

[Laszlo Ersek]

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.

Thanks
Laszlo

Re: Exporting discontiguous System Memory to EFI STUB

[Ard Biesheuvel]

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

Re: Exporting discontiguous System Memory to EFI STUB

[Laszlo Ersek]

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

Re: Exporting discontiguous System Memory to EFI STUB

[Bhupesh Sharma]

Hi Ard,

> From: Ard Biesheuvel
> Sent: Wednesday, September 21, 2016 4:50 PM
> 
> 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

Thanks. That looks promising. Can you please share the SHA-ID, commit-ID
of this *MMU fixup* patch.

Regards,
Bhupesh

Re: Exporting discontiguous System Memory to EFI STUB

[Ard Biesheuvel]

On 21 September 2016 at 12:32, Bhupesh Sharma <bhupesh.sharma@nxp.com> wrote:
> Hi Ard,
>
>> From: Ard Biesheuvel
>> Sent: Wednesday, September 21, 2016 4:50 PM
>>
[...]
>> 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
>
> Thanks. That looks promising. Can you please share the SHA-ID, commit-ID
> of this *MMU fixup* patch.
>

commit dd82465a9f0f0beff0e4d74c6e3192b966853332
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Fri Sep 9 09:01:56 2016 +0100

    ArmPkg/ArmMmuLib: base page table VA size on GCD memory map size

    As reported by Eugene, the practice of sizing the address space in the
    virtual memory system based on the maximum address in the table passed
    to ArmConfigureMmu() is problematic, since it fails to take into account
    the fact that the GCD memory space may be extended at a later time, both
    for memory and for MMIO. So instead, choose the VA size identical to the
    GCD memory map size, which is based on PcdPrePiCpuMemorySize on ARM
    systems.

    Reported-by: Eugene Cohen <eugene@hp.com>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Eugene Cohen <eugene@hp.com>
    Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>