From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Anderson Subject: Re: xm dump-core and analyzing Date: Mon, 11 Dec 2006 11:47:25 -0500 Message-ID: <457D8B9D.D8A98A8B@redhat.com> References: 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: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 11/12/06 15:59, "Dave Anderson" wrote: > > > It does -- at least for para-virtualized x86 and x86_64 xenU kernels that > > have writeable page tables. It's not clear to me whether it works on > > those xenU kernels with shadow page tables -- I have not personally > > seen it do so since we (Red Hat) ship x86/x86_64 xenU kernels > > with writeable page tables. > > > > With respect to fully-virtualized kernels, it does not work due to the > > skipping of uninstantiated pseudo-pages in the xendump page list, > > the issue that John Levon reported here: > > Cool! :-) We'd like to work on this in the Xen-3.0.5 timeframe so the xenU > dumps use a less brain-dead format (in fact, using Elf would be a good > idea!). The current format is an ancient, non-extensible and largely > unmaintained hack; since format compatibility has to be broken we may as > well fix it properly. I already discussed this a bit with John Levon in the > email thread you referenced: we should emit an Elf section for each > contiguous region of (pseudo-physical) address space and then also we will > need Elf notes for non-shadow-pagetable guests to provide the phys-machine > relationship. > 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. 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. But ELF would be a hell of lot nicer... Note that with Magnus Damm's latest hypervisor/xen0 kexec/kdump "combination" vmcore format -- which has the additional XEN_ELFNOTE_CRASH_INFO ELF note containing the dom0 pfn_to_mfn_frame_list_list value-- I can run a crash session on the vmcore from the xen0 kernel perspective, as in: $ crash xen0-vmlinux vmcore Additionally, Itsuro Oda from VAlinux has also provided a patch so that a crash session can be run on the xen-syms binary as well, as in: $ crash xen-syms vmcore When that occurs, the crash utility veers off and offers up a different set of commands appropriate to the hypervisor, i.e., instead of commands relevant to the vmlinux kernel. And lastly, from the the xen-syms crash session I can easily find the pfn_to_mfn_frame_list_list value for any other xenU guest domain, and then be able to run a crash session on any guest that was running at the time of the dom0/hypervisor crash: $ crash --p2m_mfn xenU-vmlinux vmcore Pretty nifty... Dave