This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [PATCH] kexec: framework and i386 (Take X)

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] kexec: framework and i386 (Take X)
From: Horms <horms@xxxxxxxxxxxx>
Date: Thu, 25 May 2006 16:20:19 +0900
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Kazuo Moriwaka <moriwaka@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Magnus Damm <magnus@xxxxxxxxxxxxx>, Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Delivery-date: Thu, 25 May 2006 09:30:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060518033753.GB13670@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <ADC6736C7D0580takebe_akio@xxxxxxxxxxxxxx> <E4C678D592DC26takebe_akio@xxxxxxxxxxxxxx> <3c347db5fc144e0809c47b5efe8f6582@xxxxxxxxxxxx> <E5C678D85FF5AFtakebe_akio@xxxxxxxxxxxxxx> <12c36e8e9c573c900cd75f27b3d650d3@xxxxxxxxxxxx> <20060517024402.GA13874@xxxxxxxxxxxx> <20060517045322.GA24072@xxxxxxxxxxxx> <20060517095213.GA31686@xxxxxxxxxxxx> <805b0fdb70b2ca542d6f9f43c0936928@xxxxxxxxxxxx> <20060518033753.GB13670@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.11+cvs20060403

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

      * Kexec/kdump for x86_32
      * Depends on 2 (and 1)

      * * 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
Horms                                           http://www.vergenet.net/~horms/

Attachment: 51.1-kexec-generic-upstream.patch
Description: Text document

Attachment: 51.2.1-kexec-x86-upstream.patch
Description: Text document

Description: Text document

Description: Text document

Xen-devel mailing list