Re: [Xen-devel] [PATCH 0/2] dump-core take 3

[Keir Fraser <keir@xxxxxxxxxxxxx>]

On 21/1/07 2:02 pm, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx> wrote:

> Hmm. It seems the time to change my mind. So John was right.
> I'll change the format to use sections instead of program headers.
> 
> Before coding, I'd like to clarify sections.
> (If you have more preferable names, please suggest.
> I don't stick to the following names.)
> - .Xen.core_header
> - .Xen.vcpu_context
>    Or elf note section should be used for the core header and vcpu context?
> - .Xen.p2m for non-auto translated physmode
> - .Xen.pfn for auto translated physmode
>    Or should Xen.p2m with PFN=GMFN be used?
> - .Xen.pages

This looks fine for core dump format. I think we should go with notes for
everything except GPFN-GMFN info and page data. Even those could go in a
note as well really (although I suppose it would seem a bit odd). If you
pick your own name for core-dump elf notes, do you need to start the type
numbers at 256? Seems to me you have your own brand new numbering space if
you pick a new name.

I think there will have to be differences for save/restore/migrate. For live
migration we want to stream the GPFN values (or GPFN-GMFN pairs) at the same
time as the actual page data (or in small batches) -- probably we'll do this
in a custom section format where we interleave batches of GPFN/GMFN followed
by associated page data. But this makes rather less sense for core dump
format where efficient random access to guest physical memory is desirable
(and so the format you propose makes more sense).

 -- Keir


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