[Xen-devel] guest kexec / domU boot loader

[Gerd Hoffmann <kraxel@xxxxxxx>]

  Hi,

I have some more few question/problems wrt. kexec.  They are not
strictly kexec-related, I think any complete control pass-over from one
kernel to another has them, i.e. if someone wants to combine mini-os and
grub to build a boot loader the same issues will come up:

Problem number one are the different "magic" pages: start info, shared
info, xenstore, console.  Right now they are allocated at a random place
in guest physical memory (depending on kernel and initrd size).  One
problem with that is that they are in the area where you might want to
load a kernel to.  Sure you can map them somewhere else in virtual
space, but if you want to keep things very simple for a mini-kernel or
bootloader and create a simple virt==phys identity-mapping it's a nasty
special case.

Is it possible to move those magic pages to a different place in guest
physical memory?  With and without auto_translated_physmap?  I think
start_info is easy as it can be simply copied.  shared_info isn't in the
guests physical memory so it isn't a issue I think.  The console page
and the xenstore page are not so easy.  I think without
auto_translated_physmap the guest can move them around by updating the
p2m and m2p tables.  With auto_translated_physmap I see no obvious way
to do that though.  Hints?

Problem two is passing the p2m table and handle page holes which might
be in guest physical memory, no idea yet how to handle that best.

Problem tree is that the current initial page table setup created by the
domain builders doesn't include a low memory identity mapping.  Creating
such a mapping from a in-domain boot loader and then jump to the entry
point isn't trivial ...

cheers,

  Gerd

-- 
Gerd 'just married' Hoffmann <kraxel@xxxxxxx>
I'm the hacker formerly known as Gerd Knorr.
http://www.suse.de/~kraxel/just-married.jpeg

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel