Re: E820 memory allocation issue on Threadripper platforms

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.01.2024 11:13, Roger Pau Monné wrote:
> On Wed, Jan 17, 2024 at 09:46:27AM +0100, Jan Beulich wrote:
>> Whereas I assume the native kernel can deal with that as long as
>> it's built with CONFIG_RELOCATABLE=y. I don't think we want to
>> get into the business of interpreting the kernel's internal
>> representation of the relocations needed, so it's not really
>> clear to me what we might do in such a case. Perhaps the only way
>> is to signal to the kernel that it needs to apply relocations
>> itself (which in turn would require the kernel to signal to us
>> that it's capable of doing so). Cc-ing Roger in case he has any
>> neat idea.
> 
> Hm, no, not really.
> 
> We could do like multiboot2: the kernel provides us with some
> placement data (min/max addresses, alignment), and Xen let's the
> kernel deal with relocations itself.

Requiring the kernel's entry point to take a sufficiently different
flow then compared to how it's today, I expect.

> Additionally we could support the kernel providing a section with the
> relocations and apply them from Xen, but that's likely hm, complicated
> at best, as I don't even know which kinds of relocations we would have
> to support.

If the kernel was properly linked to a PIE, there'd generally be only
one kind of relocation (per arch) that ought to need dealing with -
for x86-64 that's R_X86_64_RELATIVE iirc. Hence why (I suppose) they
don't use ELF relocation structures (for being wastefully large), but
rather a more compact custom representation. Even without building PIE
(presumably in part not possible because of how per-CPU data needs
dealing with), they get away with handling just very few relocs (and
from looking at the reloc processing code I'm getting the impression
they mistreat R_X86_64_32 as being the same as R_X86_64_32S, when it
isn't; needing to get such quirks right is one more aspect of why I
think we should leave relocation handling to the kernel).

> I'm not sure how Linux deals with this in the bare metal case, are
> relocations done after decompressing and before jumping into the entry
> point?

That's how it was last time I looked, yes.

Jan

> I would also need to check FreeBSD at least to have an idea of how
> it's done there.
> 
> Thanks, Roger.