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

To: Gerd Hoffmann <kraxel@xxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] Xen Guest Kexec
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Mon, 27 Feb 2006 14:29:11 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Horms <horms@xxxxxxxxxxxx>
Delivery-date: Mon, 27 Feb 2006 14:34:39 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43FF19C3.2070409@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200507071816.28830.mark.williamson@xxxxxxxxxxxx> <200602231449.52242.mark.williamson@xxxxxxxxxxxx> <43FF19C3.2070409@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.1
> > 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 ...

When I was looking at this approach I was intending to retreive the pageframe 
info from Xen and just run unpin on anything pinned, according to its type.

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

Actually I was talking rubbish there anyhow; of course if you don't disable 
paging the identity mapping isn't a problem.

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

When did you try that?  I've not tried it outside Xen, but it didn't look like 
a requirement from my reading of the code.

A really big chunk of the generic kexec code is there to make sure the new 
kernel is not loaded in an area that conflicts with its destination, much of 
the trampoline is there to enable the new kernel to be copied on top of the 
old one.  Address conflicts should only be an issue if you want the second 
kernel to be a dump kernel, in which case it needs to run in-place after 


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