| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] Xen Guest Kexec
> 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
|
|
|
| |
|
Home