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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Tue, 2006-11-28 at 17:28 +0900, Magnus Damm wrote:
> 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.

OK. 

> > > 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.

I was talking about the note type values but now that you mention it the
data structures would be good too ;-) I think it's useful to have shared
types & data structures defined in a shared location to avoid confusion.

It's something we can deal with some other time though.

> > > 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.

It seems to me that once backtracking code exists (it already does?) it
can be used for dom0 too and the field becomes unnecessary.

Anyway, I don't feel that strongly about it and it's only one extra
field so leave it in if you think it is useful.

> > > > 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!

Cheers.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel