Re: Would a cleanup+extending of docs/multiboot.h be acceptable?

[Goswin von Brederlow]

Hi,

haven't heard from you in a few days now. So here is some progress report:

"Vladimir 'φ-coder/phcoder' Serbinenko" <address@hidden> writes:

> On 08.04.2011 16:43, Goswin von Brederlow wrote:
>> "Vladimir 'φ-coder/phcoder' Serbinenko" <address@hidden> writes:
>>
>>> On 07.04.2011 19:32, Goswin von Brederlow wrote:
>>>> I see that you have added 32bit MIPS support. No 64bit x86_64 support
>>>> though. So my trampoline + 64bit kernel stuff would still be interesting
>>>> to people.
>>> We already have the needed infrastructure to load in 64-bit mode. Have a
>>> look at loader/i386/bsd.c. Mostly you just need to use
>>> grub_relocator64_boot and not grub_relocator32_boot. The main issue is
>>> clear specification of intended behaviour.
>> I'm adding an implementation of this to kvm, proof of concept kind of
>> way. For that I'm assuming the following changes to the specs:
>>
>> // Why is this in steps of 4?
>> #define MULTIBOOT_ARCHITECTURE_X86_64  8
>> #define MULTIBOOT_ARCHITECTURE_MIPS64  12
>>
> Because the lower 2 bits pertain to the number of bits on platform.
> 0 -> 32
> 1 -> 64
> 2 -> 16
> 3 -> everything else
> Are you familiar with mips? Unlike on x86, mips32 and mips64 don't refer
> to different modes but mips32 is a subset of mips64. So unless you're
> familiar with mips, leave this part out for now.

I implemented 64bit support in qemu-kvm now. This comes in 2 flavours:

1) 64bit elf file with multiboot1 header or MULTIBOOT_ARCHITECTURE_I386

The file is loaded and the entry point is jumped to in 32bit mode. The
only new thing here is that kvm doesn't refuse to load an 64bit elf
file. The kernel must still follow the multiboot specs for 32bit images
and manage the transition to 64bit itself. The advantage of this is that
compiling a 64bit kernel as 64bit elf file (with just a little 32bit
startup code thrown in) is a lot simpler than putting 64bit code into a
32bit elf.

2) True 64bit kernel

I've added

  #define MULTIBOOT_ARCHITECTURE_X86_64  1

If this is set in the header the kernel entry point is jumped to in
64bit mode with an identity mapping for the lower 4GB ram. The
bootloader magic and tags pointer are passed in registers acording to
the C calling convention on x86_64. Only thing missing is the stack. The
startup code becomes as simple as this:

  multiboot_entry:
        /* Initialize the stack pointer.  */
        movl    $(stack + STACK_SIZE), %esp

        /* Now enter the C main function...  */
        call    EXT_C(cmain)

Addresses (except for the mmap tag that already has 64bit fields) are
32bit so the kernel needs to be compiled below 4GB.

You can test this with the patches in

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621529

I've included a example kernel based on the 32bit kernel from the specs.
Just a few adjustements in casts and using va_list for printf() to fit
the x86_64 C calling conventions.


I've been wondering if we could add a 64bit flag to the multiboot1 specs
that would call the entry point in 64bit while leaving all data
structure as is. But if multiboot2 has it then personally I don't need
it in older loaders.

>> All structures remain as they are. That means that addresses must be
>> below 4GB (maybe even 2GB or sign extention screws things up) unless
>> they are defined as 64bit (memory mappings use 64bit, entry point only
>> 32bit). The kernel + modules must be loaded below 4GB (2GB?).
>>
> No. For 64-bit mode all fields must be extended to 64-bit and kernel and
> modules can be loaded anywhere

If you intend to do this then please make those changes soon so I can
finish the patches for qemu-kvm.



As for other changes I think it would be nice to have a tag for the
stack. This would allow the kernel image to specify an initial stack and
allow using a C function as entry point.

And last I think you forgot to change struct
multiboot_header_tag_module_align. That has the same definition as
struct multiboot_header_tag_framebuffer and "depth" doesn't make sense
for module alignment.

MfG
        Goswin