L4Linux on AMD64 (again)

[Adam Lackorzynski]

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
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/