On 11/27/06, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
On Mon, 2006-11-27 at 18:19 +0900, Magnus Damm wrote:
> I do however
> agree with you that it is strange that only certain registers are
> saved and many system-level processor registers are unsaved.
I can see why they were not included since they aren't really useful in
the normal core dump case. Perhaps it is worth talking to the native
kdump people about defining a new core note type which includes the
extended processor state that isn't in the regular core note?
That sounds like a good idea, at least in theory. The number of
patches-per-year accepted for the kexec kernel code is unfortunately
pretty low...
We can go with a Xen specific one for now and transition to a common one
later if necessary.
I think that is better solution, at least for now.
> The current Xen specific note is only written once and it is used to
> give system-wide information, ie not per cpu information. So maybe it
> makes sense to create a new per-cpu note for system-level register
> information?
That makes sense to me.
Could you also #define the note types in a header somewhere. Perhaps
xen/include/public/kexec.h or xen/include/public/elfnote.h?
Do you mean the data structures or the type value used in the elf note
header? Part of the data structures are currently dragging in
architecture-specific stuff, so I'm not that tempted... The tools
that use the data structures duplicate them anyhow, but maybe it's a
good idea.
> > You also store dom0's pfn_to_mfn_frame_list_list in a Xen specific note.
> > What is that used for? Given a Xen symbol table it should be possible to
> > locate the shared info for any domain via the xen mappings and hence
> > find the p2m table that way. m2p is at a known virtual address already.
>
> This is because Dave wanted to be able to parse dom0 kernels easily.
> I'm not sure if that is the case still with the new xencrash code?
> Dave, are you listening?
>
> I thought that pointing out pfn_to_mfn_frame_list_list for dom0 was a
> better, more portable way to provide Dave with this info than just
> handing out CR3.
Unless you provide this list for all domains[*] the CR3 method will have
to be implemented anyway so domains != 0 can be examined. In particular
it could be useful to examine the domain which made the hypercall which
led to a crash and that might not necessarily be dom0 (although I
suppose it is most likely).
This was just to make it easy to support dom0 only. Extracting other
domains are done through backtracking of symbols and data structures
which is independent of elf notes.
[*]If I understand correctly saving per domain information is not
possible because the notes need to be created when the kdump kernel is
loaded and the number of domains is unknown at that time.
Correct!
> > The contents of the h/v taint bitmap would be another interesting thing
> > to include in the Xen note.
>
> This sounds like system-wide information, not per-cpu right?
I've added that one now. Thanks!
/ magnus
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
| 
Home