Hi, On Wed Oct 02, 2013 at 03:31:43 +0400, Alexander Tarasikov wrote:
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?
It is, however, no ETA so far.
- 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?
It is written to the vCPU but there should not be anything different than for 32bit. For the page table code itself I guess it's basically in the same way as for 32bit and there isn't much code disabled.
- What load_addr should be used? Zero or 0x100000 (I suspect the former).
You mean where L4Linux is linked to? I think 2MB is a good value there.
Adam