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


Re: [Xen-devel] [PATCH]: kexec: framework and i386

To: Horms <horms@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH]: kexec: framework and i386
From: Don Zickus <dzickus@xxxxxxxxxx>
Date: Fri, 7 Apr 2006 11:00:29 -0400
Cc: Magnus Damm <magnus@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 07 Apr 2006 07:57:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060407074234.GA19846@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: <20060407074234.GA19846@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/
On Fri, Apr 07, 2006 at 04:42:36PM +0900, Horms wrote:
> kexec: framework and i386
> Here is a first cut of kexec for dom0/xen, which will actually
> kexec the physical machine from xen. The approach taken is
> to move the architecture-dependant kexec code into a new hypercall.
> Some notes:
>   * machine_kexec_cleanup() and machine_kexec_prepare() don't do
>     anything in i386. So while this patch adds a framework for them,
>     I am not sure what parameters are needs at this stage.
>   * Only works for UP, as machine_shutdown is not implemented yet
>   * kexecing into xen does not seem to work, I think that 
>     kexec-tools needs updating, but I have not investigated yet
>   * I don't believe that kdump works yet
>   * This patch was prepared against xen-unstable.hg 9514
>     As of today (9574) two new hypercalls have been added.
>     I rediffed and moved the kexec hypercall to 33. However
>     this exceedes hypercall_NR, which is currently 32. 
>     I tried increasing this, but the dom0 now crashes 
>     in entry.S on init. Even after rebuilding both xen and the kernel
>     completely from scratch after a make distclean. Help!!

I was looking at doing the same but focusing more on kdump initially.
However, the more I understood kexec/kdump and the more I understood the
hypervisor and xend, I realized they both were solving the same problem in
two different ways.  

Instead I was trying to focus on a domain0 failover/backup copy.  By
utilizing xend to set up all the infrastructure of loading the
image/initrd, I all I had to do was set a flag in the hypervisor letting
it know this was a second copy of another domain0.  

Upon reboot/crash, the hypervisor could then look to see if there is a
second copy of a domain0 and if so run that copy (which would perform the
same functionality as kexec AND kdump - minus the memory hole).  

This has the advantage (if done correctly) of not having to reboot the
domainU kernels (which is a _huge_ win).  The only penalty is dealing with
the couple of seconds when the domain0 switches block/net driver control
to the other domain0 and any dropped transactions. 

The infrastructure in xen is there, I am slowing weeding through the lower
layers to set the right bits and such.  Unfortunately, I can't commit all
my time to this little project but this is the direction I am trying to
head towards.  (Any help would be great!)

Like I said, this is my 2cents.  I just thought this approach would be a
better fit with xen, than trying to drag the whole kexec/kdump layer
inside the hypervisor.  Opinions are welcomed.


Xen-devel mailing list