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
|
Home