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

[Don Zickus <dzickus@xxxxxxxxxx>]

On Mon, Apr 10, 2006 at 02:09:17PM +0900, Hirokazu Takahashi wrote:
> Hi Don,
> 
> > > 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
> 
> 
> Would you let me confirm my understanding is correct?
> 
> You prefer kexec/kdump approach to take over a crashed domain0
> than HA approach where the backup domain stands by.
> This is because the former can reset its whole hardware
> while it would be harder with the latter, right?
> 
Actually the opposite.  I prefer the HA approach over kexec/kdump.  It
seemed like it gave more flexibility (reset dom0 or the whole machine).  

As much as I would like to see kexec/kdump in xen, for some reason it just
doesn't make sense to me.  


Cheers,
Don

> 
> Thanks,
> Hirokazu Takahashi.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel