WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

On Sun, Jan 21, 2007 at 10:05:42AM +0000, Keir Fraser wrote:
> Can you give some description of your Elf format? If we plan to use Elf for
> save/restore as well, it would be nice to pick a format that is
> generalisable to both cases. 

I'll document it.


> The use of program headers seems weird (since
> there is no sensible 'virtual address' to specify, as the Xen core dump
> format is not defined in the context of a simple single address space) and
> is going to be no use for live migration where we need to be able to specify
> GPFN-GMFN relationships on the fly, presumably in a custom section format.

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


> Are there any tools to parse this new dump format, or will we have to wait
> for the crash utility and xc_ptrace_core() to catch up?

No. I'll work on xc_ptrace_core() unless someone else does.
Probably it would be after ia64 support.
--
yamahata

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