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?
Thanks,
Hirokazu Takahashi.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home