Hello Dave, # I append crash-utility list to Cc From: Dave Anderson <anderson(a)redhat.com&gt; Subject: Re: crash with Xen dom0 image from kdump Date: Thu, 01 Jun 2006 08:39:01 -0400 > Kazuo Moriwaka wrote: > > > Hello, > > > > From: Dave Anderson <anderson(a)redhat.com&gt; > > Subject: Re: crash with Xen dom0 image from kdump > > Date: Wed, 31 May 2006 16:20:15 -0400 > > > > > > > > Hey guys, > > > > > > I've got the vmcore file from which Kazuo generated the > > > "simulated" xendump dumpfile. I have a question regarding > > > the makeup of the the vmcore file -- are the physical addresses > > > referred to by each PT_LOAD segment based upon: > > > > > > 1. machine addresses, or > > > 2. pseudo-physical addresses as perceived by the dom0 vmlinux kernel? > > > > > > Dave > > > > It's 1. > > vmcore is made by kexec-ed linux kernel (not on xen, but on machine) kdump. > > The kernel doesn't know about xen or domains except register info. > > Register info is for dom0. > > > > Ok, good... > > Next question -- how did you find dom0's phys_to_machine_mapping[] > array from the vmcore in order to create the xendump? I use xen executable binary with symbols to find 'dom0' global symbol in xen. In x86_32 arch, dom0->vcpu[0].arch->guest_table has pagetable address for domain0 guest kernel. After it, I found 'phys_to_machine_mapping'. For other domains, 'domain_list' is point list of struct domain. I'll attach my latest dom0cut script. 'dom0cut_x86_32.py' contains names of symbols and structs to get dom0 image.

> > p.s. > > Do you have any plan to support xen hypervisor itself with crash? > > If there's, I want to help it. > > > > I don't -- at least at this time. (My next primary task is to get crash > working with x86 PAE kernels.) > > But it would be an interesting project > to undertake. I'm not sure whether or how it would cleanly fit into > the crash source code, or whether it should be an executable of > its own. But by all means, if you want to undertake the task, be > my guest! I'm also not sure about them, yet. In anyway, at first, I'll help you to support xen's vmcore format. It is also a part of a way to support xen hypervisor. regards, -- Kazuo Moriwaka <moriwaka(a)valinux.co.jp&gt; ------------------------------------------------------------------------------------------------------------------------ Name: dom0cut.tar.gz dom0cut.tar.gz Type: Unix Tape Archive (application/x-tar) Encoding: base64 Download Status: Not downloaded with message Name: libelf-0.1.0.tar.gz libelf-0.1.0.tar.gz Type: Unix Tape Archive (application/x-tar) Encoding: base64 Download Status: Not downloaded with message

Kazuo Moriwaka wrote: With a xendump, the phys_to_machine_mapping array can be found by following the page tables from any of the cr3 values found in the dump header. It would seem simple enough to have the xen/kdump code store a legitimate dom0 cr3 value somewhere in the ELF header. Would that be possible to explore? Note that I'm not really interested in the other guest domains, at least at this point, but I could see it potentially helpful to recreate the crash environment for the guest domains as well, so perhap an array of per-domain cr3 values in an ELF header note section would be possible?

Horms wrote: >On Fri, Jun 02, 2006 at 09:28:07AM -0400, Dave Anderson wrote: > >>Kazuo Moriwaka wrote: >> >>With a xendump, the phys_to_machine_mapping array can be >>found by following the page tables from any of the cr3 values >>found in the dump header. >> >>It would seem simple enough to have the xen/kdump code store >>a legitimate dom0 cr3 value somewhere in the ELF header. Would >>that be possible to explore? Note that I'm not really interested >>in the other guest domains, at least at this point, but I could see >>it potentially helpful to recreate the crash environment for the >>guest domains as well, so perhap an array of per-domain cr3 >>values in an ELF header note section would be possible? >> > >I haven't looked into this, but yes I think that should be quite >possible as I believe that dom0's cr3 is stored in the hypervisor >somewhere. The main problem (for me) is where to put the extra crash >note and how to add it without having to modify the user-space kexec >tool - currently that code does not need to be modified in order to work >with xen. Would it be enough to have it stored in a symbol in the >hypervisor (to be honest I don't really understand why crash notes are >needed at all given that there is a symbol table)? Or alternatively, >could you give me suggestions on the crash-note front? I'll chase up >where dom0's cr3 is currently saved. > It's conceivable, but highly unlikely, that it can be found in the vmcore in its current state. My suggestion of storing at least one cr3 for dom0, and even better, an array of cr3's for all of the domains, was based upon how I figure it out now using the xendump format. It's just that for domains with writable page tables, I at least need a starting point "hook"; and with a legitimate cr3 (that has the kernel mappings), I can then walk the domain's page tables (all of which contain mfn's instead of pfn's in the case of writable page table domains). (Note that there's some churn going on with the kexec/kdump patch to replace its current manner of over-writing the pgd in use at the dump of the crash -- it's not clear to me whether that would be a problem until such time as that kdump quirk is "fixed".) But it would also be possible if I could access the domain's xen_start_info->mfn_list value, I could also re-create the list of mfn's that make up the list of pages in each domain's phys_to_machine_mapping array. The kernel does this, based upon what its max_pfn value is determined to be: phys_to_machine_mapping = alloc_bootmem_low_pages( max_pfn * sizeof(unsigned long)); memset(phys_to_machine_mapping, ~0, max_pfn * sizeof(unsigned long)); memcpy(phys_to_machine_mapping, (unsigned long *)xen_start_info->mfn_list, xen_start_info->nr_pages * sizeof(unsigned long)); So my wild guess was that I could possibly find the xen_start_info structures stored in the vmcore as it exists now, but that's probably impossible. I don't know enough about the hypervisor code. And again, I don't see why something could *not* be found in the xen symbol table *now*, but my point was that it unnecessarily adds the burden of having to incorporate that file in the process, instead of simply needing the vmlinux and vmcore file. Using a PT_NOTE section is simply one manner of passing arbitraray data back to the ultimate user of the vmcore file. Dave

------------------------------------------------------------------------ -- Crash-utility mailing list Crash-utility(a)redhat.com https://www.redhat.com/mailman/listinfo/crash-utility