Hi,
sorry for the somewhat long delay between sending updates.
I'm happy to announce tenth take of the kexec/kdump patch.
I'll address Keir's questions from the 9th release below,
but first I would like to quickly summarise the patches.
Kexec/kdump is implemented by moving the privelaged portions
(and related plumbing where needed) from linux into the hypervisor.
This is primarily done by implementing kexec's architecture
independent hooks as hypercalls.
Both Kexec is working for x86_32 and x86_64 for SMP and UP.
Kdump is also working for SMP and UP on x86_32. x86_64 may work,
but still needs more attention. In particular the register
saving code has not been implemented.
These patches also include some reworking of kexec's internals in
order that the page table is not mangled on kdump. These changes
also make x86_64 kexec/kdump somewhat easier to implement.
Collectively this is the pagetable_a approach developed by my colleague
Magnus Damm, and he is working with the linux kexec maintainers to
get it merged there.
The code is broken out into four patches.
They should apply cleanly to xen-unstable.hg 10151.
1. 51.1-kexec-generic-upstream.patch
* Common code for all architectures,
the basic plumbing for kexec/kdump
2. 51.2.1-kexec-x86-upstream.patch
* Glue between 1, and 3 and 4.
This would not be needed for ppc or ia64, but
neither have been written yet.
We are planning to commence work on ia64 soon.
* Depends on 1
3. 51.2.1.1-kexec-x86_32-upstream.patch
* Kexec/kdump for x86_32
* Depends on 2 (and 1)
4. 51.2.31.2-kexec-x86_64-upstream.patch
* * Kexec/kdump for x86_64
* Depends on 2 (and 1)
On Thu, May 18, 2006 at 12:37:54PM +0900, Horms wrote:
> On Wed, May 17, 2006 at 11:10:45AM +0100, Keir Fraser wrote:
> >
> > On 17 May 2006, at 10:52, Horms wrote:
> >
> > >as promised earlier in the day, here is an update on the kexec/kdump
> > >patch. The main changes are that SMP now works, and the dumping of
> > >cpu registers for kdump has been moved into the hypervisor so as to
> > >allow all CPUs to be captured, not just dom0's VCPUs.
> >
> > Just looking at the generic patch:
> > * Define KEXEC_CMD_* in your public kexec.h header, not xen.h.
> > * Don't pack all the different arg structs into a union -- the union
> > will change in size if you ever add a bigger argument substructure,
> > plus it's ugly. Split them out and put a comment by each KEXEC_CMD_*
> > definition explaining what its argument parameter points at (see other
> > header files like vcpu.h for an example).
I have changed both of these things.
> > * Can you explain the need for all the changesin your kexec.patch? I
> > guess there are some virt_to_phys address translations that need fixing
> > up, but you also scatter a few hypercalls around in there (e.g., in
> > base/cpu.c) -- can they not be handled more cleanly, or is kexec-on-xen
> > somehow more special than kexec on any native architecture?
Sure. There are several areas of change, I will address them one by one.
If I have missed any, please let me know
* pfn vs mfn
Linux kexec works in pfns, but as kexec needs to work in real mode
in Xen mfns are needed. This change should be fairly obvious, though
more invasive than I would have liked.
* get_crash_notes
When a kernel is loaded for kexec or kdump part of the work
is done in user-space. In particular the elf header is created in
user-space and it needs to know the location of the elf notes
where the registers are saved on crash dump. As only xen knows
where all the CPUs the notes are handled by the hypervisor and
a hypercall is used by get_crash_notes() to get the address of the
notes which is exposed to userspace as required by kexec-tool.
It is worth noting that only dom0's vcpus are exposed to user space,
however all CPUs notes will be written by xen. In practice I stronly
suspect that a customised tool will be needed to analyise crash dumps,
well the xen specific parts anyway, and such a tool should
be able to find the crash notes that are not in the elf header.
Actually, I'm not really sure why the crash notes need to be in the
elf header at all. In essence this code is really just there to keep
kexec-tool happy and avoid having to modify it. To that end I am
happy to say that neither kexec-tool nor the target kernel (crash or
kexec kernel) need to be modified in order to kexec or kdump from xen.
* xen_machine_kexec_load and xen_machine_kexec_unload
It was originally hoped that the machine_kexec_prepare and
machine_kexec_cleanup hooks could be used, however it turns out
that the place that they are called in is not very useful for xen.
Well, on x86_32 and x86_64 at least. So instead xen_machine_kexec_load
and xen_machine_kexec_unload were added.
xen_machine_kexec_load loads the kernel into xen. It is at this time
that all preparation is work is done. Leavking xen_machine_kexec as
just a trigger. xen_machine_kexec_unload reverses the work of
xen_machine_kexec_load.
--
Horms http://www.vergenet.net/~horms/
51.1-kexec-generic-upstream.patch
Description: Text document
51.2.1-kexec-x86-upstream.patch
Description: Text document
51.2.1.1-kexec-x86_32-upstream.patch
Description: Text document
51.2.1.2-kexec-x86_64-upstream.patch
Description: Text document
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home