From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Anderson Subject: Re: [PATCH 00/04] Kexec / Kdump: Release 20061122 (xen-unstable-12502) Date: Tue, 28 Nov 2006 09:01:30 -0500 Message-ID: <456C413A.9B2DD113@redhat.com> References: <20061122071050.24010.92547.sendpatchset@localhost> <1164219848.12608.78.camel@localhost.localdomain> <456B03FE.171DE907@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Magnus Damm Cc: Ian Pratt , Kazuo Moriwaka , xen-devel@lists.xensource.com, Ian Campbell , Akio Takebe , Isaku Yamahata , Magnus Damm , Horms List-Id: xen-devel@lists.xenproject.org Magnus Damm wrote: > On 11/28/06, Dave Anderson 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. Dave