Kazuo Moriwaka wrote:
> Hi Dave,
>
> From: Kazuo Moriwaka <moriwaka@xxxxxxxxxxxxx>
> Subject: Re: dom0cut script updated
> Date: Wed, 13 Sep 2006 11:34:20 +0900 (JST)
>
> > Hi Dave,
> >
> > > > Have you abandoned the idea of adding an ELF note (or some other
> > > > mechanism) for passing the "pfn_to_mfn_frame_list_list" mfn value
> > > > from the shared, per-domain, "arch_shared_info" structure(s)?
> >
> > I talked with our kdump patch managers. They don't want to change
> > kernel level codes.. I'm sorry for I didn't tell this to you. I'll
> > talk with them again.
>
> pfn_to_mfn_frame_list_list can included into ELF core :)
Yay!
>
> I think you need shared_info.arch.max_pfn, too, don't you?
>
In my prototype, I did not need shared_info.arch.max_pfn because
the page that the pfn_to_mfn_frame_list_list mfn references can
only contain a hardwired number of entries, i.e., 16 on x86, and
512 on x86_64:
arch/i386/kernel/setup-xen.c:
unsigned long *pfn_to_mfn_frame_list[16];
arch/x86_64/kernel/setup-xen.c:
unsigned long *pfn_to_mfn_frame_list[512];
So I can just walk through the array, and stop on either (1) a zero-filled
entry, or (2) the end of the array.
All I need to know is what the new ELF note "NT_xxx" n_type value
will be. Recall that in your test vmcore last June, you used an n_type
value of 0x10000001, which meant that you were passing a cr3 value.
The only other non-standard NT_xxx value recognized by the crash utility
is the diskdump-specific NT_DISKDUMP note (0x70000001).
>
> > > Furthermore -- if you could pass the "pfn_to_mfn_frame_list_list" mfn
> > > values for all existing domains, it would be possible to bring up
> > > crash sessions for dom0, as well as for any of the domU's -- all
> > > with a single unmodified vmcore.
> >
> > It sounds good.
>
> Writing variable length data in ELF core header with kexec-tool is
> difficult, because ELF core header length should be fixed when kexec loads
> kdump kernel. It makes multiple domain support difficult by this technique.
>
Right, I understand. Just having dom0's pfn_to_mfn_frame_list_list mfn
would be great.
>
> Using domain_list and idle_pg_table (and follow domain list to find
> domain) is one solution; but it needs to treat xen hypervisor address
> space and xen data structures.
>
Right -- I understand. Again, as far as the new ELF note is concerned,
just the dom0 mfn would be great.
If it were absolutely necessary to bring up a session for one of the
domU sessions, their per-domU mfn values could be determined
later by:
(1) dom0cut the /proc/vmcore to make a xen vmcore, and get the
domU mfns from there, or
(2) perhaps a quick-and-dirty utility could be written that digs out
the mfn values from the original vmcore, by using the xen data
structures/symbols, and then just dumps them out to the screen?
In any case, having determined the mfn for any of the domU sessions,
a new crash command line option could be created to pass in any of
the domU mfn values, which could over-ride the dom0 mfn value in the
new ELF note.
But again, just having dom0's mfn would be outstanding.
Thanks,
Dave
>
> regards,
> --
> Kazuo Moriwaka <moriwaka@xxxxxxxxxxxxx>
>
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
