Linux Virtualization - Apr 2007 - [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

Jeremy Fitzhardinge <jeremy@goop.org> writes:
> Eric W. Biederman wrote:
>> All it does is set a flag that tells a bootloader.
>> "Hey. I can run when loaded a non-default address, and this is
what
>>  you have to align me to."
>>
>> All relocation processing happens in the kernel itself.
>>   
>
> Is it possible to decompress and extract the kernel image from the
> bzImage without executing it?  Ie, is there enough information to find
> the compressed data part of the bzImage by inspection?
>
> At some point we'll need to change the Xen domain builder to handle
> bzImage files, and it would be best if we didn't need to run them.
/sbin/kexec bzImage ....

There is a 32bit entry point that is reasonably well specified
you can use.  I'm guessing you want to recover the 64bit ELF,
with all of your nice ELF notes etc.  vmlinux is run through
"objcopy -O binary" as part of the bzImage build process so all
of the ELF metadata is lost.

I have several ideas on how we can make this work but first I have to
ask what is it that you are trying to accomplish?

<rant>
  Right now I'm a little frustrated that insanity below slipped into
  head.S right after the 32bit entry point after the review said
  use the normal linux parameters for parameter passing.
  
  > #ifdef CONFIG_PARAVIRT
  >         movl %cs, %eax
  >         testl $0x3, %eax
  >         jnz startup_paravirt
  > #endif
  
  The whole thing should be based on a value in the linux parameter block
  pointed to by %esi, instead of the insane preserve all registers and
  attempt to be super compatible with everyone.

  Yes we do need a branch there, but no we don't need to be changing 
  the format we pass arguments to the kernel in.
</rant>

Anyway since it seems there is interest in going farther in tweaking
the linux boot process let's open thread up to what is needed/wanted
for future enhancements to linux booting, and let's see if we can
design something that works and isn't brain dead.

Eric

On Sun, 2007-04-29 at 09:11 -0600, Eric W. Biederman
wrote:
>   Right now I'm a little frustrated that insanity below slipped into
>   head.S right after the 32bit entry point after the review said
>   use the normal linux parameters for parameter passing.
>   
>   > #ifdef CONFIG_PARAVIRT
>   >         movl %cs, %eax
>   >         testl $0x3, %eax
>   >         jnz startup_paravirt
>   > #endif
>   
>   The whole thing should be based on a value in the linux parameter block
>   pointed to by %esi, instead of the insane preserve all registers and
>   attempt to be super compatible with everyone.
Dammit, Eric, you spend a lot of time using words like "insane" where
you mean we didn't do everything all at once.

It's *not* clear that using %esi is sane, but nothing in the current
code prevents that.

I was trying to get Xen to use this entry point rather than their own: I
failed, and only lguest now uses it.

Fortunately, this also means it's trivial to change.
Rusty.

Eric W. Biederman wrote:
> I have several ideas on how we can make this work but first I have to
> ask what is it that you are trying to accomplish?
>   
The requirements are:

   1. the domain builder needs to get various information about the
      guest kernel by inspecting its ELF notes
   2. we start the kernel in 32-bit mode with paging enabled, in ring 1
   3. the guest kernel needs various pieces of runtime information from
      the hypervisor about its runtime environment

At the moment we just load a bare vmlinux kernel with a xen-specific
entrypoint, so 1 and 2 are easy.  3 is achieved by having the domain
builder start the kernel with %esi pointing to a Xen info structure
which tells the kernel what it needs to know.

That works OK for a kernel which is compiled to run under Xen and can't
run in any other environment, but now that we can generate a single
kernel which can run in any number of different environments, its
unfortunate that we still need multiple variants of the kernel image.

Clearly the Xen domain builder needs to be extended to deal with a
bzImage format kernel directly, so we can use the same actual kernel
image for native and Xen booting.  Since we're changing the domain
builder anyway, I can change the details of how it works so long as the
3 requirements can still be met.

So, I have no problem in also building a boot protocol info structure,
and passing that in %esi, so long as I can store a pointer to the
Xen-specific info as well.  Some info will be duplicated, like the
initrd location, but that's OK.

I'd already reserved a Xen bootloader ID specifically with this in mind;
all I really need is a place where I can stash the pointer.

I think I'd prefer to have the domain builder decompress/relocate the
kernel from the bzImage and start it directly, rather than have it
decompress/relocate itself, but I'm not really set on that.  It depends
on how well it can deal with having paging enabled and being in ring 1. 
Looks like it might just be a matter of starting up with "enough"
memory
mapped.

So the biggest unknown is where to put the Xen ELF notes.

    J

Eric,

i tried to load vmlinux with kexec and got
Ramdisks not supported with generic elf arguments

So i use mkelfImage with my patch ( convert elf64 to elf32) to make
another elf32. and loaded with kexec and can not get vga console too.
---serial console works well.

the mkelfImage 2.7 patch is at
http://72.14.253.104/search?q=cache:fuxOvFw3ZIIJ:lists.osdl.org/pipermail/fastboot/attachments/20061108/009064a6/attachment.obj+mkelfImage+2.7+patch&hl=en&ct=clnk&cd=4&gl=us

So the problem is not bzImage related, but in somewhere in vmlinux.

YH

> the mkelfImage 2.7 patch is at
https://lists.linux-foundation.org/pipermail/fastboot/attachments/20061108/009064a6/mkelfImage_2.7_amd64_1108-0001.obj

YH

On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
> Eric,
> 
> i tried to load vmlinux with kexec and got
> Ramdisks not supported with generic elf arguments
> 
This message generally appears if you did not specify --args-linux
on kexec command line while loading vmlinux.

Thanks
Vivek