Re: [Xen-devel] [PATCH 00/04] Kexec / Kdump: Release 20061122 (xen-unstable-12502)

["Magnus Damm" <magnus.damm@xxxxxxxxx>]

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