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/
Home Products Support Community News


[Xen-ia64-devel] Re: [PATCH] kexec: framework and i386 (Take XIV)

Hi, Horms and Magnus

Good work. :-)
I have one commet.

I believe crash_kexec should be directly called 
when unknown NMI is occurred.
In your patch, crash_kexec is called as the bellow.
  1. unknown NMI is occurred. (e.g. by pushing NMI botton)
  2. xen recieved NMI and call do_nmi.
  3. xen report to dom0 by using raise_softirq(NMI_SOFTIRQ).
  4. dom0 call crash_kexec of dom0.
  5. crash_kexec of dom0 call crash_kexec of xen

Am I correct?
The above process is not reliable if I'm correct.
So I belive crash_kexec of xen should be directly called like the 
following patch.

diff -r 9611a5c9e1a1 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c      Thu Aug 31 13:12:26 2006 +0900
+++ b/xen/arch/x86/traps.c      Thu Aug 31 17:40:19 2006 +0900
@@ -1612,6 +1612,7 @@ asmlinkage void do_nmi(struct cpu_user_r
         else if ( reason & 0x40 )
         else if ( !nmi_watchdog )
+            crash_kexec(NULL);
             unknown_nmi_error((unsigned char)(reason&0xff));

What do you think about it?

Best Regards,

Akio Takebe

>here is an update of the kexec/kdump patchset.
>* Up port to xen-unstable.hg-11296 (45f6ee334fcc)
>  - kexec hypercall number fragment is now in xen-unstable
>* Make kexec_page_to_pfn and friends need to be architecture specific
>  - this abstraction is needed to support ia64
>* Use kexec_page_to_pfn in machine_kexec_setup_load_arg()
>  - this abstraction is needed to support ia64
>* Rename do_kexec to do_kexec_op to make it consistent with other
>  hypercalls
>* Add ppc stubs
>* Add ia64 support
>Seems to be working fine
>Probably working fine, but I can't test this as dom0 refuses to boot for
>me on xen-unstable-11388 (50aea0ec406b).  That is, even without the
>kexec patches. I'm not sure what the problem is and I've devicided to
>get these patches out rather and investigate later.
>This patchset also, for the first time, includes ia64 code.
>Please note that this currently does _not_ work. I am actually
>struggling to work out why, and would really appreaciate it
>if someone could cast an eye over it.
>One possible area of concern is that relocate_kernel wipes out TLB
>entries. However many of the entries instated in
>arch/ia64/xen/xenasm.S:ia64_new_rr7() are not wiped. In particular,
>VHPT_ADDR, Shared info, and Map mapped_reg are not handled by
>relocate_kernel(), and the handling of current seems to be different.
>There are also problems with constants inside kexec_fake_sal_rendez.
>However this function probably also suffers the same problems as
>relocate_kernel. And it is easy not ro run kexec_fake_sal_rendez
>by booting xen with maxcpus=1, thus avoiding calling
>kexec_fake_sal_rendez, which is used in cpu shutdown.
>stubs only
>   1. 51.1-kexec-generic-upstream.patch
>      * Common code for all architectures,
>        the basic plumbing for kexec/kdump
>   2. 51.1.1-kexec-trigger_crash_dump.patch
>      * xen-console trigger crash_dump
>      * Depends on 1
>   3. 51.2.1-kexec-x86-upstream.patch
>      * Glue between 1, and 3 and 4.
>      * Depends on 1
>   4.
>      * Kexec/kdump for x86_32
>      * Depends on 3 (and 1)
>   5.
>      * Kexec/kdump for x86_64
>      * Depends on 3 (and 1)
>   6. 51.2.2-kexec-ia64-upstream.patch
>      * Kexec/kdump for ia64
>      * Depends 1
>Email is always good. Also my partner in crime, Magnus Damm,
>will be at Xen Summit.
>  H: http://www.vergenet.net/~horms/
>  W: http://www.valinux.co.jp/en/

Xen-ia64-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>