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
|
Home