On 10.08.2020 19:09, Andrew Cooper wrote:
> On 06/08/2020 10:06, Jan Beulich wrote:
>> Address at least the primary reason why 52bba67f8b87 ("efi/boot: Don't
>> free ebmalloc area at all") was put in place: Make xen_in_range() aware
>> of the freed range. This is in particular relevant for EFI-enabled
>> builds not actually running on EFI, as the entire range will be unused
>> in this case.
>>
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>> ---
>> The remaining issue could be addressed too, by making the area 2M in
>> size and 2M-aligned.
>
> This memory range is only used for relocating the (synthesized?)
> multiboot strings, is it not?
No. Afaict it has nothing to do with multiboot strings. There are
exactly two uses afaics - in place_string() and in
efi_arch_allocate_mmap_buffer(). The former is used to record
command line pieces, e.g. that parsed from the config file, while
the latter is what allocates the memory for the EFI memory map.
> I'm not actually convinced that this is a sensible tradeoff.
>
> For one, you've broken setup.c's:
>
> /* This needs to remain in sync with xen_in_range(). */
> reserve_e820_ram(&boot_e820, __pa(_stext), __pa(__2M_rwdata_end));
>
> which covers the runtime aspect of what xen_in_range() covers during boot.
Hmm, I did specifically look at that and thought it wouldn't need
changing. But now that you point it out (again), it looks like I
was wrong.
> I think the better course of action is to go with David Woodhouse's work
> to not relocate the trampoline until later on boot (if even necessary),
> at which point both of the custom allocators can disappear.
Well, in the light of my response above I'd like to express that
I can't see how David's work would make this allocator go away.
Jan
