From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Levon Subject: Re: xm dump-core and analyzing Date: Mon, 11 Dec 2006 23:55:18 +0000 Message-ID: <20061211235518.GD22288@totally.trollied.org> References: <457D8B9D.D8A98A8B@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <457D8B9D.D8A98A8B@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dave Anderson Cc: xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org On Mon, Dec 11, 2006 at 11:47:25AM -0500, Dave Anderson wrote: > Cool right back at you! > > Nothing would make me happier than to see the xendump format > replaced by an ELF format vmcore -- as long as I can make the > p2m translations. Seconded (thirded?). ELF is a perfect format for this since it's extendable and naturally understood by the debuggers we all have. > I "get by" now with paravirtualized x86/x86_64 writeable page table kernels > because even though there are holes in the array of mfn's with respect > to their associated pfn's in the xendump file, I can: > > (1) take the machine address of the cr3 from the xendump header, > (2) walk the (writeable) page tables to find the "phys_to_machine_mapping" symbol, > (3) read what's there, and then re-create the phys_to_machine_mapping[] array of the > dumped kernel. > > And from that point on, all p2m translations can be made by looking at that > re-created table for the mfn associated with any pfn, and then looking up > the mfn in the xendump corefile. How do you know what address that symbol is at? It's a requirement for us that the dump is completely stand-alone. Ideally we would get this issue fixed for 3.0.4, but I haven't found time to work on the full fix that Keir suggested :/ regards john