Kazuo Moriwaka wrote: > Hello Dave, > # I append crash-utility list to Cc > > From: Dave Anderson <anderson@xxxxxxxxxx> > 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@xxxxxxxxxx> > > > 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. The problem is that we're just going to want to work with the /proc/vmcore and vmlinux file as always. Having to drag the xen executable binary into the picture should be unnecessary. 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? Dave > > > > > 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@xxxxxxxxxxxxx> > > ------------------------------------------------------------------------------------------------------------------------ > 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