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

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

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?

Daniel

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