Re: [PATCH]: kexec: framework and i386

[Don Zickus <dzickus@redhat.com>]

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.

Cheers,
Don