Re: [Xen-devel] [PATCH v3 12/16 - RFC] x86/efi: create new early memory allocator

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Thu, Jun 02, 2016 at 02:11:32AM -0600, Jan Beulich wrote:
> >>> On 01.06.16 at 21:53, <daniel.kiper@xxxxxxxxxx> wrote:
> > On Wed, Jun 01, 2016 at 10:02:51AM -0600, Jan Beulich wrote:
> >> >>> On 01.06.16 at 17:58, <daniel.kiper@xxxxxxxxxx> wrote:
> >> > On Fri, May 27, 2016 at 02:37:06AM -0600, Jan Beulich wrote:
> >> >> >>> On 25.05.16 at 21:48, <daniel.kiper@xxxxxxxxxx> wrote:
> >> >> > On Wed, May 25, 2016 at 02:39:57AM -0600, Jan Beulich wrote:
> >> >> >> >>> On 15.04.16 at 14:33, <daniel.kiper@xxxxxxxxxx> wrote:
> >> >> >> > There is a problem with place_string() which is used as early 
> >> >> >> > memory
> >> >> >> > allocator. It gets memory chunks starting from start symbol and
> >> >> >> > going down. Sadly this does not work when Xen is loaded using 
> >> >> >> > multiboot2
> >> >> >> > protocol because start lives on 1 MiB address. So, I tried to use
> >> >> >> > mem_lower address calculated by GRUB2. However, it works only on 
> >> >> >> > some
> >> >> >> > machines. There are machines in the wild (e.g. Dell PowerEdge R820)
> >> >> >> > which uses first ~640 KiB for boot services code or data... :-(((
> >> >> >> >
> >> >> >> > In case of multiboot2 protocol we need that place_string() only 
> >> >> >> > allocate
> >> >> >> > memory chunk for EFI memory map. However, I think that it should 
> >> >> >> > be fixed
> >> >> >> > instead of making another function used just in one case. I 
> >> >> >> > thought about
> >> >> >> > two solutions.
> >> >> >> >
> >> >> >> > 1) We could use native EFI allocation functions (e.g. 
> >> >> >> > AllocatePool()
> >> >> >> >    or AllocatePages()) to get memory chunk. However, later 
> >> >> >> > (somewhere
> >> >> >> >    in __start_xen()) we must copy its contents to safe place or 
> >> >> >> > reserve
> >> >> >> >    this in e820 memory map and map it in Xen virtual address space.
> >> >> >> >    In later case we must also care about conflicts with e.g. crash
> >> >> >> >    kernel regions which could be quite difficult.
> >> >> >>
> >> >> >> I don't see why that would be: Simply use an allocation type that
> >> >> >> doesn't lead to the area getting consumed as normal RAM. Nor do
> >> >> >> I see the kexec collision potential. Furthermore (and I think I've
> >> >> >> said so before) ARM is already using AllocatePool() - just with an
> >> >> >> unsuitable memory type -, so doing so on x86 too would allow for
> >> >> >
> >> >> > Nope, they are using standard EfiLoaderData.
> >> >>
> >> >> Note how I said "just with an unsuitable memory type"?
> >> >
> >> > Could you be more precise?
> >>
> >> What else do you need? Just have the arch specify the memory type to
> >> be used (if ARM really _means_ to use that seemingly wrong type), and
> >> make the rest of the code common.
> >
> > This is not the problem. I am not sure how do you understand "seemingly
> > wrong type". Anything outside of the UEFI spec? Or maybe
> > EfiReservedMemoryType or something like that?
>
> No, the type is apparently wrong because quite likely, just like on
> x86, they want the memory map to persist past ExitBootServices().
> Sooner or later at least some parts of efi_init_memory() (or some
> equivalent thereof) will be needed on ARM afaict, and accessing the
> memory map at that time will require a change to the memory type.

I have checked the code once again. On ARM we allocate memory using
EfiLoaderData (not only for memory map) and later deliberately do not
take over these regions. This means that memory map persists. However,
this also means that we are not able to use a lot of memory which is
free from Xen point of view (for more details please check Unified
Extensible Firmware Interface Specification, Version 2.6, section 6.2,
Memory Allocation Services). Why? AFAICT, EfiLoaderCode/EfiLoaderData
types are used very often by EFI applications to allocate memory
dynamically. Most of these applications are dead after ExitBootServices().
So, there is pretty good chance that we are loosing quite big chunk
of memory which simply contains junk except of small portion with memory
map. And on ARM, especially on embedded, this could be painful.

On x86 we take over EfiLoaderCode/EfiLoaderData regions. And I do not
think we should change that behavior. Even maybe we should change
behavior on ARM. Hmmm... Is it possible? Was there a reason to not
take over EfiLoaderCode/EfiLoaderData regions on ARM?

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel