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

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> As close as possible to normal i386 kexec ...
>
> 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 ...

I doubt having paging enabled would be too painful.  i386 kexec disables 
paging right at the end of the process so that the new kernel will have a 
sensible start-of-day.  We'd just need start-of-day to contain bootstrap 
pagetables, same as for normal Linux.  Ideally you'd need to find a slot in 
the bootstrap tables for the trampoline code to live, if you take that 
approach.

You've got a load of other things to worry about in this approach, like 
un-type-pinning all pages you own, etc.

The generic kexec code doesn't understand phys vs machine memory, IIRC, so you 
may need to worry about it mis-allocating your trampoline page (this is an 
issue because you need to identity map the trampoline page later on in the 
process).

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

I patched kexec userspace, but partly that was so that it wouldn't complain 
about the Xen-format image files.  I also seem to remember I built a 
descriptor that described the size of the kernel, ramdisk, etc for the 
benefit of the kexec code but this probably wasn't strictly necessary.  I 
might even have removed that in the end...  Can't remember :-)

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

I'm not convinced: the reboot kernel doesn't need to be any different from the 
standard kernel *unless* you're running kdump (when the kernel will need to 
live in a different place so that it doesn't stomp on the main kernel - not a 
limitation of kexec).  Or am I misunderstanding what you meant?

Anyhow, it'd be nice to have kexec working.  But I'd still suggest that you 
take a quick look at my patch and consider implementing it as a platform 
service, rather than implementing all the low-level gunk.  It really is much 
less code that way.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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