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

x86-64 has paging enabled while trampoline is running too, so I can get
some ideas there ;)

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

Yep, that is a problem.  What pages are pinned (other than pgd)?  I've
seen plenty of pages with PG_pinned set, but can't figure easily what
pages that are ...

Also switching page tables seems to be not so easy.  Is it possible to
switch atomically to a new, completely independant page table tree?
i.e. old tree is valid (of cource), new tree is too, but the pages of
the old tree are not mapped read-only in the new tree (and visa versa).

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

Not a big issue if paging is enabled anyway, we can use a identity map
then (virtual == physical, not virtual == machine), so kexec doesn't
even notice outside the arch-specific code.

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

I think it's needed in both cases, at least I had problems making normal
kexec work (without xen) when both kernels had the same physical
address.  Might have been a simple bug though.



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

Xen-devel mailing list