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] kexec trouble

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] kexec trouble
From: "Magnus Damm" <magnus.damm@xxxxxxxxx>
Date: Wed, 6 Dec 2006 18:08:03 +0900
Cc: Gerd Hoffmann <kraxel@xxxxxxx>, Xen devel list <xen-devel@xxxxxxxxxxxxxxxxxxx>, Magnus Damm <magnus@xxxxxxxxxxxxx>
Delivery-date: Wed, 06 Dec 2006 01:08:01 -0800
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=biuzsFt0CqTLwnC9CIWp/lIfvPIdnE4G7Q9RM6cuTOvA64kAOdQCsvL4vvmQ0xlw9aSuRj450fHHz2xm2XgcslR9QPGgPk1zrLLv+jSU+pqK0q2XNers+N4wPTv1G5Zjex2sF+pTcDzA/5QTgz3v1p/0ZuzZRECLidKvLOVEpbo=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C19C31C6.56D8%keir@xxxxxxxxxxxxx>
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: <aec7e5c30612050753n263e19f3w8a6b58344dde3ebb@xxxxxxxxxxxxxx> <C19C31C6.56D8%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 12/6/06, Keir Fraser <keir@xxxxxxxxxxxxx> wrote:
On 5/12/06 3:53 pm, "Magnus Damm" <magnus.damm@xxxxxxxxx> wrote:

>> I think we need either wrapper functions for machine_kexec_* functions
>> which dispatch to the correct function depending on the environment
>> (dom0 vs domU, later also native) or just make them function pointers to
>> archive the same effect.  Same goes for the KEXEC_ARCH_HAS_PAGE_MACROS
>> stuff.  IMHO "#ifdef CONFIG_XEN" should go away from the core code (i.e.
>> kernel/kexec.c).
> You mean for the paravirt stuff? Isn't paravirt basically a set of
> callbacks that you can register? If so, what is stopping us from
> registering a set of paravirt callbacks for the kexec code?

I think partly Gerd's point is that CONFIG_XEN in kernel/kexec.c will never
get merged upstream. Guaranteed.

Sure, I understand that. But I see this as an iterative process, where
the our code so far has been written to fit the current codebase. When
dom0 runs on paravirt and we can test the code then it should be
adjusted. It's kind of hard to write for something that doesn't yet
exist. =) So regardless how you do it, you still need to adjust your
code towards the new interface in the end - it's just a matter of how
much code you need to adjust.

I'm all for converting the code into using runtime checks or callbacks
if that is needed, and I would have done so in the first place if I'd
known that it was something that you guys wanted. But I didn't so we
used the simplest possible solution instead which was CONFIG_XEN.

The kexec/kdump patches are not very tidy in some respects like this. We
applied them now because the functionality is useful, but I don't think we
yet have the finished polished article. Also you got away with it because
the code changes were hidden in the patches/ directory, which you originally
said was simply backported code from 2.6.19 (not backported-and-hacked-on!).

The git-patches are backports. The other ones are not:


/ magnus

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>