From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0/2] dump-core take 3 Date: Sun, 21 Jan 2007 10:05:42 +0000 Message-ID: References: <20070121074652.23834.28219.sendpatchset@ls.local.valinux.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070121074652.23834.28219.sendpatchset@ls.local.valinux.co.jp> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Isaku Yamahata , xen-devel@lists.xensource.com Cc: John Levon , Dave Anderson , xen-ia64-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 21/1/07 7:46 am, "Isaku Yamahata" wrote: > The following patchset is the dump-core take 3. > It changes its format into ELF, adds PFN-GMFN table, HVM support, > and adds IA64 preliminary chages. These patches look much better. Can you give some description of your Elf format? If we plan to use Elf for save/restore as well, it would be nice to pick a format that is generalisable to both cases. The use of program headers seems weird (since there is no sensible 'virtual address' to specify, as the Xen core dump format is not defined in the context of a simple single address space) and is going to be no use for live migration where we need to be able to specify GPFN-GMFN relationships on the fly, presumably in a custom section format. Are there any tools to parse this new dump format, or will we have to wait for the crash utility and xc_ptrace_core() to catch up? -- Keir