<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
David Anderson wrote:<br>
<blockquote type="cite" cite="mid4484312E.5000705@redhat.com">
<title></title>
Horms wrote:<br>
<blockquote type="cite" cite="mid20060605011034.GA10650@verge.net.au">
<pre wrap="">On Fri, Jun 02, 2006 at 09:28:07AM -0400, Dave Anderson wrote:<br></pre>
<blockquote type="cite">
<pre wrap="">Kazuo Moriwaka wrote:<br><br>With a xendump, the phys_to_machine_mapping array can be<br>found by following the page tables from any of the cr3 values<br>found in the dump header.<br><br>It would seem simple enough to have the xen/kdump code store<br>a legitimate dom0 cr3 value somewhere in the ELF header. Would<br>that be possible to explore? Note that I'm not really interested<br>in the other guest domains, at least at this point, but I could see<br>it potentially helpful to recreate the crash environment for the<br>guest domains as well, so perhap an array of per-domain cr3<br>values in an ELF header note section would be possible?<br></pre>
</blockquote>
<pre wrap=""><!----><br>I haven't looked into this, but yes I think that should be quite<br>possible as I believe that dom0's cr3 is stored in the hypervisor<br>somewhere. The main problem (for me) is where to put the extra crash<br>note and how to add it without having to modify the user-space kexec<br>tool - currently that code does not need to be modified in order to work<br>with xen. Would it be enough to have it stored in a symbol in the<br>hypervisor (to be honest I don't really understand why crash notes are<br>needed at all given that there is a symbol table)? Or alternatively,<br>could you give me suggestions on the crash-note front? I'll chase up<br>where dom0's cr3 is currently saved.<br><br></pre>
</blockquote>
<br>
It's conceivable, but highly unlikely, that it can be found in the vmcore
in<br>
its current state. My suggestion of storing at least one cr3 for dom0,
and<br>
even better, an array of cr3's for all of the domains, was based upon how<br>
I figure it out now using the xendump format. It's just that for domains
with<br>
writable page tables, I at least need a starting point "hook"; and with
a <br>
legitimate cr3 (that has the kernel mappings), I can then walk the domain's<br>
page tables (all of which contain mfn's instead of pfn's in the case of
writable<br>
page table domains). <br>
<br>
(Note that there's some churn going on with the kexec/kdump patch to replace
its<br>
current manner of over-writing the pgd in use at the dump of the crash --
it's<br>
not clear to me whether that would be a problem until such time as that
kdump<br>
quirk is "fixed".)<br>
<br>
But it would also be possible if I could access the domain's xen_start_info->mfn_list<br>
value, I could also re-create the list of mfn's that make up the list of
pages in each<br>
domain's phys_to_machine_mapping array. The kernel does this, based upon
what<br>
its max_pfn value is determined to be:<br>
<br>
phys_to_machine_mapping = alloc_bootmem_low_pages(<br>
max_pfn * sizeof(unsigned long));<br>
memset(phys_to_machine_mapping, ~0,<br>
max_pfn * sizeof(unsigned long));<br>
memcpy(phys_to_machine_mapping,<br>
(unsigned long *)xen_start_info->mfn_list,<br>
xen_start_info->nr_pages * sizeof(unsigned long));<br>
<br>
So my wild guess was that I could possibly find the xen_start_info structures<br>
stored in the vmcore as it exists now, but that's probably impossible. I
don't<br>
know enough about the hypervisor code.<br>
<br>
And again, I don't see why something could *not* be found in the xen symbol<br>
table *now*, but my point was that it unnecessarily adds the burden of having
to <br>
incorporate that file in the process, instead of simply needing the vmlinux
and<br>
vmcore file. Using a PT_NOTE section is simply one manner of passing<br>
arbitraray data back to the ultimate user of the vmcore file. <br>
<br>
Dave<br>
<br>
<br>
<br>
<br>
</blockquote>
Forget what I said about using the xen_start_info->mfn_list above -- that<br>
won't work at all -- mfn value initially stored and copied from the "mfn_list"<br>
are immediatly free_bootmem()'d after the memcpy above.<br>
<br>
What I *meant* was that if the cr3 values were not available, another <br>
alternative would be to access the value of the pfn_to_mfn_frame_list_list<br>
in the arch_shared_info structure: <br>
<br>
typedef struct arch_shared_info {<br>
unsigned long max_pfn; /* max pfn that appears in table
*/<br>
/* Frame containing list of mfns containing list of mfns containing p2m.
*/<br>
unsigned long pfn_to_mfn_frame_list_list;<br>
unsigned long nmi_reason;<br>
} arch_shared_info_t;<br>
<br>
Each domain's xen_start_info structure has the mfn of the the "shared_info"
structure:<br>
<br>
typedef struct start_info {<br>
/* THE FOLLOWING ARE FILLED IN BOTH ON INITIAL BOOT AND ON RESUME.
*/<br>
char magic[32]; /* "xen-<version>-<platform>".
*/<br>
unsigned long nr_pages; /* Total pages allocated to this domain.
*/<br>
unsigned long shared_info; /* MACHINE address of shared info struct.
*/<br>
uint32_t flags; /* SIF_xxx flags.
*/<br>
unsigned long store_mfn; /* MACHINE page number of shared page.
*/<br>
uint32_t store_evtchn; /* Event channel for store communication.
*/<br>
unsigned long console_mfn; /* MACHINE address of console page.
*/<br>
uint32_t console_evtchn; /* Event channel for console messages.
*/<br>
/* THE FOLLOWING ARE ONLY FILLED IN ON INITIAL BOOT (NOT RESUME).
*/<br>
unsigned long pt_base; /* VIRTUAL address of page directory.
*/<br>
unsigned long nr_pt_frames; /* Number of bootstrap p.t. frames.
*/<br>
unsigned long mfn_list; /* VIRTUAL address of page-frame list.
*/<br>
unsigned long mod_start; /* VIRTUAL address of pre-loaded module.
*/<br>
unsigned long mod_len; /* Size (bytes) of pre-loaded module.
*/<br>
int8_t cmd_line[MAX_GUEST_CMDLINE];<br>
} start_info_t;<br>
<br>
and the shared_info structure contains the arch_shared_info structure<br>
show above.<br>
<br>
So it would appear that given the mfn of the xen_start_info structure<br>
of a domain, then the pfn_to_mfn_frame_list_list could be tracked down.<br>
<br>
Dave<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite" cite="mid4484312E.5000705@redhat.com"><br>
<br>
<pre wrap=""><br><hr width="90%" size="4"><br>--<br>Crash-utility mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:Crash-utility@redhat.com">Crash-utility@redhat.com</a><br><a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/crash-utility">https://www.redhat.com/mailman/listinfo/crash-utility</a><br></pre>
</blockquote>
<br>
<br>
</body>
</html>