This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

On Tue, Apr 11, 2006 at 10:44:37AM +0900, Horms wrote:
> Hi Don, Hi all,
> The key reason why I think that kexec/kdump does makes sense for xen, at
> least to some extent, is for the case where the hypervisor goes into a
> bad state, and you actually want to get rid of it and kdump into
> something else for forensics. There is also the advantage that by
> kexecing xen, you get access to the entire physical machine, either for
> crash-dump analysis, or because *gasp* you want to get out of xen for
> some other crazy reason :) And, on hardware that takes forever and a day
> to reboot, I believe that doing a kexec will be quite useful for
> hypervisor development.

I guess I never thought about it from the hypervisor prospective.  ;) 
Part of my concern was that the hypervisor had a bunch of this
functionality built-in (like mapping memory and loading cpu context).

However, after re-reading some of the kexec code, you don't use the
hypervisor to load a new kernel into memory?  And I don't know enough
about the low level bits to understand if hypercall to load vcpu context
would be useful.  

> I would also like to note, that while my patch does involve moving parts
> of kexec/kdump into the hypervisor, and more similar parts need to be
> added in order to support other architectures, it is by no means all of
> kexec/kdump.

I understand what you are saying now.  The first patch you sent I skimmed
through and immediately thought you were trying to moving most parts down
into the hypervisor.  Upon reviewing it again, it doesn't seem as
intrusive.  :)


Xen-devel mailing list