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