On Wed, Jun 14, 2006 at 10:46:45AM +0900, Simon Horman [Horms] wrote: After talking things over a little with Yamahata-san (who works on xen-ia64), it seems that using vcpu->arch.guest_table is correct. I guess we shall see. I added some code to kdump to have it record CR3 for dom0. This is done using a second note in the per-cpu notes area, which for now just stores a single 4byte entity, the mfn of that CPU in dom0 if it was present in dom0. I have made a dump available that includes this. The tarball also includes the kernels, xen, symbol files, and patches to xen. If you want to find the cr3 saving code its in ./arch/x86/crash.c I plan to post this update to xen-devel shortly, hopefully tomorrow, after upporting to the latest xen tree (I'm still working off about 3 weeks ago's tree). http://packages.vergenet.net/tmp/xen-unstable.hg+kexec-20060616.tar.bz2 -- 西門 宝曼 (サイモン・ホーマン) | Simon Horman (Horms)

On Wed, Jun 14, 2006 at 09:29:10AM -0400, Dave Anderson wrote: I expect so too. With a little bit of luck kexec will be merged into xen in the not to distant future, hopefully that will bring more eyes to the problem. I guess that should be easy enough to do. Now we have the separate note we potentially can store quite a number of things. 3) You can generate a domU crash using sysrq. I have a patch, which I think I included in the tarball, that allows you to generate a hypervisor panic from the xen console, which is availble over serial. enter xen console: ctrl-a ctrl-a help: h panic: p In a nutshell the it is the hypervisor not the dom0 kernel that performs kexec/kdump. Or in other words, userspace asks dom0 to load a kernel, which in turn just passes it on to the hypervisor. From there its just a matter of activating the new kernel, and that can be triggered from within they hypervisor, or from dom0 using a hypercall. The resulting dump should be much the same, with the exception that if dom0 crashes then the crashing CPU's registers are saved by dom0 and passed to the hypervisor, and in the case where they hypervisor crashes, it saves the crashing CPU's regisers. Regardless, the hypervisor saves the non-crashing CPU's registers. Part of the motivation for allowing the hypervisor trigger perform kexec/kdump without needing data from dom0 (other than what is passed at load time) is to allow hypervisor panics to cause kdump. And part of it is becasuse only the hypervisor has access to all of system memory, the mmu, and all of the cpus. I don't think there were any other significant parts :) -- Horms http://www.vergenet.net/~horms/