From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Zickus Subject: Re: [PATCH]: kexec: framework and i386 Date: Wed, 12 Apr 2006 11:56:12 -0400 Message-ID: <20060412155612.GS30208@redhat.com> References: <20060407074234.GA19846@verge.net.au> <20060407150029.GF30208@redhat.com> <20060410.140917.116374331.taka@valinux.co.jp> <20060410153837.GM30208@redhat.com> <20060411014437.GC5979@verge.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20060411014437.GC5979@verge.net.au> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Horms Cc: Hirokazu Takahashi , magnus@valinux.co.jp, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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