Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

[Gerd Hoffmann <kraxel@redhat.com>]

Jeremy Fitzhardinge wrote:
> 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

Doesn't need to be ELF notes.  The current (3.0.5+) domain builder has 
pluggable binary parsers.  Right now there are two:  ELF (obviously ...) 
and binary (with a multiboot-like header).  Filling the informations 
such as virt_base is a function of the parser, so when adding one more 
parser to the domain builder for bzImage kernels the parser could do 
something completely different to gather the needed information ...

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

Yep, although already much better than completely different kernels. 
Most space of a typical distro kernel is modules which are shared even 
with different kernel binaries.

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

Yep, should work fine.

> 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,

I'd expect that work better too.

> It depends
> on how well it can deal with having paging enabled and being in ring 1. 

Xen direct paging mode requiring (leaf) page tables being mapped 
read-only makes page table manipulation a bit difficult.  Xen has to 
care whenever the memory it maps is a page table.  Native hasn't.

Also switching to a completely different set of page tables isn't easy 
under Xen.  My xen guest kexec patches have to perform some intresting 
tricks because of that ...

> Looks like it might just be a matter of starting up with "enough" memory
> mapped.

Doesn't solve the problem of having to switch from identity mapping to 
the 0xc0000000 one ...

cheers,
   Gerd