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

To: Gerd Hoffmann <kraxel@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH]: kexec: framework and i386
From: Horms <horms@xxxxxxxxxxxx>
Date: Sat, 8 Apr 2006 13:39:32 +0900
Cc: Magnus Damm <magnus@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 10 Apr 2006 06:45:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4436809B.5040601@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060407074234.GA19846@xxxxxxxxxxxx> <4436809B.5040601@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.11+cvs20060126
On Fri, Apr 07, 2006 at 05:09:15PM +0200, Gerd Hoffmann wrote:
>   Hi,
> > 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.
> First you need some more security checks.  On a first quick look it
> seems you can zap and takeover the whole machine from within a domU by
> kexec-booting the machine.

Yes, I think you are right, I had completely forgotten about that.

> Second I think we'll need a new kexec flag to indicate we'll go zap the
> physical machine, not the virtual machine.  I'm looking into the later,
> and I think we'll be able to do both at some point in the future.  Maybe
> it is enougth to care about dom0 (physical machine kexec) vs. domU
> (virtual machine kexec) only though.  We certainly don't want allow
> domUs kexec the whole machine, and virtual machine kexec for dom0
> doesn't make that much sense given how tight xen and dom0 work hand-in-hand.

Sounds fine by me. The focus of what I was trying to achive is to zap
the entire physical machine, which is what the current code does. I am
actually most interested in kdump, though its not working yet. In any
case a flag makes perfect sense. Though it might make sense to add it
when more flexible incarnations of kexec are added.

> >   * kexecing into xen does not seem to work, I think that 
> >     kexec-tools needs updating, but I have not investigated yet
> Yep, actually _alot_ of the kexec magic happens in userspace.

Yes, I became aware of that along the way. I'm pretty confident that
the way I have done things, if you fixed up user-space kexec so
that linux -> xen worked, then xen -> xen would also work.


Xen-devel mailing list