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

[Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>]

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 )
             io_check_error(regs);
         else if ( !nmi_watchdog )
+            crash_kexec(NULL);
             unknown_nmi_error((unsigned char)(reason&0xff));
     }
 }

What do you think about it?

Best Regards,

Akio Takebe

>Hi,
>
>here is an update of the kexec/kdump patchset.
>
>Summary:
>
>* 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
>
>Architectures:
>
>x86_32: 
>
>Seems to be working fine
>
>x86_64:
>
>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.
>
>ia64:
>
>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.
>
>ppc:
>
>stubs only
>
>Patches
>
>   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. 51.2.1.1-kexec-x86_32-upstream.patch
>      * Kexec/kdump for x86_32
>      * Depends on 3 (and 1)
>
>   5. 51.2.31.2-kexec-x86_64-upstream.patch
>      * Kexec/kdump for x86_64
>      * Depends on 3 (and 1)
>
>   6. 51.2.2-kexec-ia64-upstream.patch
>      * Kexec/kdump for ia64
>      * Depends 1
>
>Discussion:
>
>Email is always good. Also my partner in crime, Magnus Damm,
>will be at Xen Summit.
>
>-- 
>Horms
>  H: http://www.vergenet.net/~horms/
>  W: http://www.valinux.co.jp/en/



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