Re: [PATCH] mutliboot2 second round

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sun, Feb 02, 2020 at 02:58:51AM +0000, Emmanuel Dreyfus wrote:
> On Thu, Jan 30, 2020 at 09:24:44PM +0100, Joerg Sonnenberger wrote:
> > I still don't get why you need 32bit C code or even the memmove. What
> > exactly are the constraints of the entry point? 32bit protected mode without
> > paging to an unknown physical address without any guarantees about
> > alignment?
> 
> The initial memmove() is required because the code in locore assumes
> the kernel loads at fixed address KERNTEXTOFF-KERNBASE (that is
> 2MB) while EFI loads it much higher (0x4136000 with OVMF/qmeu). I
> understand this happens because there is EFI boot service data
> memory in the way around 2MB. It gets released when bootloader
> calls ExitBootServices(), which is why we can safely memmove() to 2MB.
> 
> Of course the approach is not bullet-proof, since some other EFI
> implementation could have some other stuff around 2MB that
> cannot be released. Addressing that would require intrusive change
> in locore so that the code can run after loading a dynamic location 
> other than KERNTEXTOFF-KERNBASE. 

The regular bootstrap is position independent as far as the physical
address is concerned. It only requires the alignment to match the
alignment of the virtual addresses. The boot sequence is essentially:
(1) Build page table with identity map of the low ranges (<4GB) and
correct mapping for KERNBASE etc.
(2) Enable paging and long mode.
(3) Jump into the non-identity mapped range.
That's essentially found in locore.S 663ff. If multiboot ensures page
alignment, you can basically just follow the same procedure. If it
doesn't, the easiest approach is likely to depend on BSS being large
enough and move the kernel up one page, e.g. write a small relocation
stub to the second page after the start of the BSS, jump to it, REP
MOVSB the kernel and jump back to the correctly aligned location.

Joerg