Hi, l4-hackers!
This message is mainly directed to Adam because most of the work on
the latest revisions of l4linux was done by him.
I have noticed that AMD64 support is present in most of the arch-l4
code, so I have tried compiling the l4linux kernel in the amd64 mode.
I have uncommented the “default y” switch in the KConfig to enable
CONFIG_X86_64. Then, I fixed some minor compilation issues:
* entry.S did not compile. I had to replace the bitwise or with
summation, and replaced the X86_EFLAGS_BIT1 with the integer constant
(well, I think I could’ve replaced it with X86_EFLAGS_FIXED)
* replaced BIT1 with FIXED in some file, I think, head64.c
* added the definition of the early page table count to head64.c (it
*is* defined in pgtable-64.h, but I was lazy to figure out why it was
not properly included)
Then, I applied the amd64 patch to L4Re bootstrap (the one in the
mailing list) and raised the modaddr to 0x4000000 to work around
region conflicts. I have also launched qemu with 512M memory.
First of all, the kernel crashed at the SLAB allocator because the
cache pointer was uninitialized. Actually, it nanged in the
“arch-l4/kernel/main.c” before calling start_kernel. The reason was
that the “head_64.c” contained the code to clean the “early page
tables” which wrote to the CR3 register. I have commented the writing
to the CR3 and it allowed to move a bit further. Subsequently, I have
commented out all the code in the file.
SLAB allocator fails to allocate because the function
“setup_cpu_cache” in the “mm/slab.c” file has the “init_refok”
attribute which means it gets placed into the “ref” section. Selecting
SLOB allocator makes it go further.
Then, it crashed at the “console_init” call. Console_init calls
con_init in “drivers/tty/vt.c”, which freezes at the “pr_info”
statement (for some weird reason, it does not jump into the printk()
from pr_info). It started working after I lowered the default printk
level, so it’s a minor issue.
Some more crashes were related to the debug/kmemleak init calls, vfs
cache setup which I commented out. Eventually, I had the kernel output
the debug via the ttyLv0, not via LOG_printf. It complained about some
memory which was not within e820 range.
The kernel did not fully boot, because the “init_rest” routine is also
marked with “init_refok”. So, I think that only the code from the text
section works and the pointers to other sections are invalid.
Hope my findings will be useful. Now, I have some questions which
could save a few hours of debugging. I would be very grateful if you
could answer them:
* Is amd64 support planned soon?
* Could you explain which part of page table manipulation functions
are needed, and which can be commented out? Should the page directory
be written somewhere in vCPU instead of CR3?
* What load_addr should be used? Zero or 0x100000 (I suspect the former).
vG8tQK?z,P-UC`a
--
Regards, Alexander
