On 05/15/12 11:44, John Baldwin wrote:
> The i386 kernel assumes it starts out with a flat 32-bit mode with
> the kernel loaded into a contiguous memory region at a fixed
> physical address. If we need a relocatable kernel (as Marcel
> hinted at I think), then that adds a fair bit of complication.
>
> The amd64 kernel assumes it starts in long mode (the bootinfo64.c
> bits in the loader setup initial page tables, etc.). I think the
> amd64 kernel also has to be loaded into contiguous memory at a
> fixed physical address currently.
>
Seems like an initial workaround could be to allocate a space big
enough for all the necessary ELF segments, and split it up ourselves.
Do the kernel and modules actually do anything that depends on being
in a contiguous space in some way (ie some relocation trick)? Because
it seems like it shouldn't really matter otherwise.
> Nah, nothing in amd64 calls the BIOS (we don't support VM86). The
> only thing I am aware of is the VESA bits but those use an
> emulator, they don't let the CPU natively run BIOS routines. i386
> could be adopted to do the same, but it also doesn't make BIOS
> calls on modern systems outside of the VESA driver (it used to use
> VM86 to probe memory, but now it uses the SMAP passed in by the
> loader if it exists and only falls back to VM86 calls if it
> doesn't).
Yeah, I've seen the x86emu code, when I was trying to track down a
suspend/resume problem. The thing I'm wondering is if the BIOS
info/code will even be there at all when EFI booting. I suppose the
only way to really know is to get the kernel booting and see...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
Delicious
Digg
reddit
Facebook
StumbleUpon
