[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |