WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 00/04] Kexec / Kdump: Release 20061122 (xen-unsta

To: "Dave Anderson" <anderson@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 00/04] Kexec / Kdump: Release 20061122 (xen-unstable-12502)
From: "Magnus Damm" <magnus.damm@xxxxxxxxx>
Date: Wed, 29 Nov 2006 11:35:36 +0900
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Kazuo Moriwaka <moriwaka@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Magnus Damm <magnus@xxxxxxxxxxxxx>, Horms <horms@xxxxxxxxxxxx>
Delivery-date: Tue, 28 Nov 2006 18:35:37 -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=GHQX1EZLq3vot4Z8atKtNkQkyNnCDquYsi4Bjl+Dmsr/AfqQsJXoLcf5w91+76Zuhpb1PrCeGzXgpJBhkrBtZMTPBZ5jPDWFgjDLi3RJRyLexs110mfsa4R4vWHh3QaPhUcPaw7jkf+Bd84kA0cl9pCb4yN3jXSV0I9IX8otLrQ=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <456C413A.9B2DD113@xxxxxxxxxx>
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: <20061122071050.24010.92547.sendpatchset@localhost> <1164219848.12608.78.camel@xxxxxxxxxxxxxxxxxxxxx> <aec7e5c30611270119v2f1c3f99ge2ccfd97a59cce39@xxxxxxxxxxxxxx> <456B03FE.171DE907@xxxxxxxxxx> <aec7e5c30611280030t1df98149me32990d620bdcbf9@xxxxxxxxxxxxxx> <456C413A.9B2DD113@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 11/28/06, Dave Anderson <anderson@xxxxxxxxxx> wrote:
Magnus Damm wrote:

> On 11/28/06, Dave Anderson <anderson@xxxxxxxxxx> wrote:
> > Magnus Damm wrote:
> > > I thought that pointing out pfn_to_mfn_frame_list_list for dom0 was a
> > > better, more portable way to provide Dave with this info than just
> > > handing out CR3.
> > >
> >
> > That's correct.  With this simple additional note, it will be possible
> > to do any of the following:
> >
> >   $ crash vmlinux vmcore       (with the NT_XEN_KDUMP_CR3 note)
> >   $ crash xen-syms vmcore    (with the new "xencrash" patch)
> >   $ gdb xen-syms vmcore
> >
> > I had originally suggested an array of pfn_to_mfn_frame_list_list values,
> > one for each guest domain, in which case you could execute crash
> > sessions for dom0 or any of the guest domains.
> >
> > And now with the new xencrash patch, the crash utility can also
> > be run against the xen-syms binary, which means that the session
> > will be run from the perspective of the hypervisor binary, i.e., with its
> > own set of hypervisor-specific commands.
> >
> > Anyway, we compromised on just the dom0 pfn_to_mfn_frame_list_list
> > value, given that in the majority of dom0/hypervisor crashes, the cause
> > of the crash will most likely be in the dom0 kernel code.
>
> Thanks for the comments! The value for NT_XEN_KDUMP_CR3, do you have
> any strong feelings to keep that? We have an unique string now, so I'm
> tempted to just set it to 0...
>

Obviously as long as it doesn't clash with the NT_XXX type #define's in elf.h,
it's OK.  For diskdump vmcores, they created an un-clashable NT_DISKDUMP
type value of 0x70000001, and so the use of 0x10000001 for NT_XEN_KDUMP_CR3
apparently followed that model.  But, since you're asking, I don't particularly
like the use of 0; it just seems too ambiguous.

Hm... But doesn't both the string and the type together form an unique
identifier?

I think the "CORE" string together with the NT_PRSTATUS type point out
a structure of type ELF_Prstatus. In the case of our Xen specific
notes we use "XEN CORE" as string and therefore are free to use any
type because we are already "unique enough" with our string. So I was
kind of questioning having both an unique string and on top of that an
unique type.

Thanks,

/ magnus

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

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