This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH] Xen Guest Kexec

Mark Williamson wrote:
> How are you planning to do domU kexec?

As close as possible to normal i386 kexec ...

> For domUs the major problem I found was:
> a) the existing kexec code doesn't understand pseudophysical memory
> b) we had no way (at the time) of resetting virtual devices - disconnecting 
> cleanly and then reconnecting again
> c) creating a start-of-day environment for the reboot kernel duplicates a 
> load 
> of code that's already in the domain builder

Dis- and reconnecting should be ok by now I guess.  I expect the paging
setup being the most tricky part:  First because the pseudophysical
memory (probably not a major issue though).  Second because unlike i386
kexec we'll have to run with paging enabled all the time ...

My plan is to first make xenlinux kernels work with correct ELF headers
(patches on the list last days ;), then make kexec userspace work
(unmodified if possible), last step the in-kernel stuff which performs
the actual kexec ...

> For dom0 kexec, I thought the best approach would be to port the existing 
> Linux kexec machinery to Xen (should be quite straightforward - just the part 
> which copies the kernel image to the correct place, switches off paging, 
> jumps into the new kernel).  Then the dom0 kexec code would make a hypercall 
> after closing its devices, rather than trying to execute that code itself.

Right now linux kexec depends on the new kernel having a different
physical (and virtual) start address, so taking the very same approach
likely doesn't work.



Gerd 'just married' Hoffmann <kraxel@xxxxxxx>
I'm the hacker formerly known as Gerd Knorr.

Xen-devel mailing list