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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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