[Xen-ia64-devel] [RFC] dump core is failed for PAL_HALT
Hi, all
In linux side, panic() call smp_send_stop() before panic_notifier_list.
And smp_send_stop() call PAL_HALT.
So we cannot coredump guest memory,
because smp_send_stop call domain_shutdown(SHUTDOWN_poweroff).
Which way shold we choice?
A. we don't call smp_send_stop in panic()
B. we don't call PAL_HALT in xen_pal_emulator(),
and we call EFI_RESET_SYSTEM in machine_halt().
A is very easy and simple, but we must modify common code.
If we choice B, we must fix domain_shutdown() and machine_halt().
I think B is probably better, but are there anything else to fix?
In linux, panic() is the below.
59
60 NORET_TYPE void panic(const char * fmt, ...)
61 {
[snip...]
90 #ifdef CONFIG_SMP
91 /*
92 * Note smp_send_stop is the usual smp shutdown function, which
93 * unfortunately means it may not be hardened to work in a panic
94 * situation.
95 */
96 smp_send_stop();
97 #endif
98
99 atomic_notifier_call_chain(panic_notifier_list, 0, buf);
100
In xen, PAL_HALT is the below.
381 struct ia64_pal_retval
382 xen_pal_emulator(unsigned long index, u64 in1, u64 in2, u64 in3)
383 {
[snip...]
603 case PAL_HALT:
604 if (current-domain == dom0) {
605 printk (Domain0 halts the machine\n);
606 console_start_sync();
607 (*efi.reset_system)(EFI_RESET_SHUTDOWN,0,0,NULL);
608 }
609 else
610 domain_shutdown(current-domain,
SHUTDOWN_poweroff);
611 break;
Best Regards,
Akio Takebe
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/2] dump-core take 3
On Sun, Jan 21, 2007 at 10:05:42AM +, 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-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [RFC] dump core is failed for PAL_HALT
On Sun, Jan 21, 2007 at 10:56:26PM +0900, Akio Takebe wrote: In linux side, panic() call smp_send_stop() before panic_notifier_list. And smp_send_stop() call PAL_HALT. So we cannot coredump guest memory, because smp_send_stop call domain_shutdown(SHUTDOWN_poweroff). Which way shold we choice? A. we don't call smp_send_stop in panic() B. we don't call PAL_HALT in xen_pal_emulator(), and we call EFI_RESET_SYSTEM in machine_halt(). Choice C. Modify PAL_HALT emulation as follows. If other vcpu is left and alive, vcpu is put in sleep. If current is the last vcpu, call domain_shutdown(SHUTDOWN_poweroff). It will be guaranteed that the vcpu which call panic() calls HYPERVISOR_shutdown(SHUTDOWN_crash) via xen_panic_block so that the guest domain's core dump should be created. (I haven't tested it though.) -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [PATCH 0/2] dump-core take 3
On Sun, Jan 21, 2007 at 03:28:37PM +, Keir Fraser wrote: 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? No. 256 doesn't have special meaning. Just a number which doesn't used. See below. Seems to me you have your own brand new numbering space if you pick a new name. Yes in thery. Unfortunately binutils and elfutils don't see name. They simply check number and report type. So I thought that it was better to avoid the number which is commonly used. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
