Re: Exporting discontiguous System Memory to EFI STUB

[Bhupesh Sharma <bhupesh.sharma@nxp.com>]

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