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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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