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.
