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

[Goswin von Brederlow <goswin-v-b@web.de>]

"Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com> 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

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?).

The system state when leaving the bootloader is like in 32bit but
modified as follows:

- PAE is enabled
- Paging is enabled
- Long mode is enabled
- Long mode is active
- CS contains a 64bit code segment
- the lower 4GB of memory are mapped 1:1 accessible R/W to Ring 0 and in
  2MB granularity

I'm tempted to add 2 new info tags: multiboot_tag_gpt and
multiboot_tag_page_tables. The later would contain the number of tables
and an array of pointers to the pages. But that might be too i386/x86
specific.

MfG
        Goswin