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

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

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?

Daniel

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