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
|
Home