Re: OpenSolaris and multiboot

Re: OpenSolaris and multiboot

[Hollis Blanchard]

This is great information, so I hope you don't mind if I CC grub-devel.

On Mon, 2006-11-20 at 17:13 -0800, Joe Bonasera wrote:
> 
> I guess I should give you some background on how Solaris uses
> grub 0.9x. One important thing to remember is that when you install
> Solaris you get both the 64 bit kernel and 32 bit kernel. Hence
> you always have the choice of at boot time to go 32 or 64 bit.
> Currently Solaris 10 and OpenSolaris have a grub entry
> that looks like:
> 
> title Solaris
>      kernel multiboot [/platform/i86pc/[amd64/]unix] [ -B bootprop=value[,...]] [-v] [-k] etc..
>      module /platform/i86pc/boot_archive
> 
> The multiboot program is the vestiges of our pre-grub boot loader
> that basically just decides if this is a 64 bit capable machine or
> not. If the machine can boot 64 bits, it boots the 64 bit kernel,
> otherwise it falls back to the 32 bit kernel. You can explicit
> tell it which kernel executable to boot as an argument.
> 
> We're just about to change all that and eliminate the multiboot
> program all together.  The Solaris entries would soon look like:
> 
> title Solaris 32 bit
>      kernel /platform/i86pc/kernel/unix [ -B bootprop=value[,...]] [-v] [-k] etc..
>      module /platform/i86pc/boot_archive
> 
> title Solaris 64 bit
>      kernel /platform/i86pc/kernel/amd64/unix [ -B bootprop=value[,...]] [-v] [-k] etc..
>      module /platform/i86pc/amd64/boot_archive
> 
> The /platform/i86pc/kernel/unix file is a 32 bit ELF, so grub
> can load it. The /platform/i86pc/kernel/amd64/uni file is ELF 64,
> so we embed a multiboot header into it and rely on grub's a.out
> hack to get it loaded appropriately. It's the only part of the
> multiboot header we use. The fields in the multiboot header are
> setup so that the entire file amd64/unix gets placed in a known location
> in memory. Then we just decode the ELF64 ourselves to relocate
> the text and data into their final virtual locations.

GRUB2's 'multiboot' command will load ELF64 files, so the "a.out hack"
shouldn't be necessary for you in the future.

And at that point, you may ask yourself why you need a multiboot header
at all. I'd like to remove that requirement entirely. The only argument
I've heard for keeping it is that
     1. The multiboot header is needed when using the a.out hack or
        specifying the VGA mode.
     2. GRUB will only search 8KB of the image looking for the header.
     3. If the header (with VGA mode) appears after 8KB due to
        programming error, GRUB would load the ELF file anyways but
        without the proper VGA mode.
     4. OS silently crashes.

This seems to be a bit of a corner case to me, especially that
"programming error" part.

There are only two pieces of information communicated via the multiboot
header: VGA mode and load addresses. The load addresses are superfluous
in ELF32/ELF64 files, so that leaves us with the VGA mode as the only
reason to keep the header in an ELF file.

> One of the problems we stumbled into was matching the old
> multiboot behavior that can boot 64 bit kernels if possible and fall
> back to 32 bit.  The way we're doing this is to actually extend
> grub. We're adding the idea of environment variables to grub that
> reflect the boot environment.  The simplest way to explain it
> is to show you how it looks:
> 
> title Solaris
>      kernel$ /platform/i86pc/kernel/$ISADIR/unix [ -B bootprop=value[,...]] [-v] [-k] etc..
>      module$ /platform/i86pc/$ISADIR/unix
> 
> 
> The idea is that "kernel$" and "module$" lines may have variables
> expanded to reflect something that grub detects about the boot
> environment. In this case if a machine is long mode capable, $ISADIR
> expands to "amd64", otherwise it's an empty string. This is useful
> for example for a live CD that automatically boots to the most
> apprpriate (32 or 64) bit kernel.
> 
> Another place where we may use variables is for ZFS root/boot partitions.
> The ZFS plugin for grub will be able to know how to choose among multiple
> bootable file systems or snapshots inside a ZFS dataset. We hope to use
> s $ZFS style variable expansion to also pass the information to the kernel.

Yup, this is a very common use case. GRUB2 supports scripting, so this
exact behavior should be possible without needing to patch anything.
Scripting support is currently incomplete, but it may actually be
possible to implement this functionality now, since variable expansion
has been working for a while.

-Hollis

Re: OpenSolaris and multiboot

[Joe Bonasera]

Hollis Blanchard wrote:

> 
> GRUB2's 'multiboot' command will load ELF64 files, so the "a.out hack"
> shouldn't be necessary for you in the future.

That's fine and will let us delete a small amount of code from both
the kernel startup sequence and the tools used to build kernel.

Just to be clear. For grub2 on x86, will it be true that there is only
a single grub2 binary that understands both elf32 and elf64?
Would the different tags i86-pc vs x86_64 (if any) be determined by
knowing if which type elf gets loaded?

Joe

Re: OpenSolaris and multiboot

[Johan Rydberg]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

Joe Bonasera <joe.bonasera@sun.com> writes:

> Hollis Blanchard wrote:
>
>> GRUB2's 'multiboot' command will load ELF64 files, so the "a.out
>> hack"
>> shouldn't be necessary for you in the future.
>
> That's fine and will let us delete a small amount of code from both
> the kernel startup sequence and the tools used to build kernel.
>
> Just to be clear. For grub2 on x86, will it be true that there is only
> a single grub2 binary that understands both elf32 and elf64?

Yes.

> Would the different tags i86-pc vs x86_64 (if any) be determined by
> knowing if which type elf gets loaded?

My personal opinion is that we should not pass any information to the
kernel about what format it is provided in.  

If the image is an ELF64, it will be loaded as an ELF64.  So in your
case, for x86_64 hosts, provide the kernel as an ELF64 image.  For
IA-32, provide an ELF32 image.

~j

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: OpenSolaris and multiboot

[Hollis Blanchard]

On Wed, 2006-11-22 at 10:41 +0100, Johan Rydberg wrote:
> Joe Bonasera <joe.bonasera@sun.com> writes:
> 
> > Would the different tags i86-pc vs x86_64 (if any) be determined by
> > knowing if which type elf gets loaded?
> 
> My personal opinion is that we should not pass any information to the
> kernel about what format it is provided in.  
> 
> If the image is an ELF64, it will be loaded as an ELF64.  So in your
> case, for x86_64 hosts, provide the kernel as an ELF64 image.  For
> IA-32, provide an ELF32 image.

I think he's referring to the "architecture-specific" tags (which are
currently not fleshed out in the spec). There are different sections for
x86 and x86-64, and it is a good question about when each is used.

I'm really not sure what would be different about the two sets, but if
there are differences, the ELF class seems like a reasonable way to
decide which to use.

-Hollis

Re: OpenSolaris and multiboot

[Yoshinori K. Okuji]

On Wednesday 22 November 2006 19:58, Hollis Blanchard wrote:
> I think he's referring to the "architecture-specific" tags (which are
> currently not fleshed out in the spec). There are different sections for
> x86 and x86-64, and it is a good question about when each is used.
>
> I'm really not sure what would be different about the two sets, but if
> there are differences, the ELF class seems like a reasonable way to
> decide which to use.

No difference, in my opinion. GRUB never activate 64-bit mode, and the 
firmware behaves exactly in the same way. Thus we don't need to pass 
different tags.

Briefly, i386 and x86_64 are treated identically in the Multiboot 
Specification. I wrote some notes about x86_64, only because I had to make it 
clear how to initialize additional registers before passing the control to a 
kernel.

Okuji