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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
