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)(reason0xff));
}
}
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@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
