[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH]: kexec: framework and i386
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |