[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.  :)

Cheers,
Don


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.