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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Mon, 2006-11-27 at 18:19 +0900, Magnus Damm wrote:
> On 11/23/06, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > Firstly the patches break native kernel compile. [snip]
>
> Sorry about the breakage. I'd like to stay away from duplicating files
> so I think merging kexec-xen.h into kexec.h sounds good. I plan to add
> the common non-xen version of the page macros to include/linux/kexec.h
> and add the xen-specific macros to the per-architecture
> include/asm/kexec.h.
> 
> I'll include a fix in the patchset that I'll send later this week.

Great, thanks.

> > My second comment is WRT to the ELF notes which you add to the kdump.
> > You include a standard PRSTATUS core ELF note per physical CPU but there
> > is some useful physical processor state which is not included in this
> > structure -- most importantly CR3.
> 
> This structure is used both for regular Linux kdumps and core dumps so
> it felt natural to extend it to the Xen case as well.

Definitely.

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

We can go with a Xen specific one for now and transition to a common one
later if necessary.

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

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

[*]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.

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

Yep.

Cheers,
Ian.


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