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][HVM] fix migration from NX-capable machine to no

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][HVM] fix migration from NX-capable machine to non-NX-capable machine
From: "Dave Lively" <dlively@xxxxxxxxxxxxxxx>
Date: Fri, 28 Sep 2007 09:23:05 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 28 Sep 2007 06:23:49 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=EWwF9uhJfaa5EwwyOiCVBS5nifnodB18KyT2vudcn9Q=; b=YGweowKZetGrTrSS4lcadPEZIKDUJUbhZO0tdAVegfry2fKDblKxpTTBL0zpGlrSMp03HGwIMt/HQMmn17mD4vxTSchk/PzLdNfQkIl5A2DzHMregjLYbvhiyCe1u1Ppx/8SG+GhTCMXGbXKxGcpf8irFN7eHfE4mtT3JXdlgbM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=WIkZ5aswNfEALEyIAn4EduQrGGP73cBVZe7H4976ws/1tqoXsQ2Xcccti61wPBKPtDwhsj1hNcIAxUWjVvC+LvGjWGyKCZqfVrTAKSYqRFnKxAhKgz+hcKqE8iuS5bMSD/iZVqbt/R7uKbgB34BFNvG+JmQlohqLIQ2BKS7eXDM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3226945.E247%Keir.Fraser@xxxxxxxxxxxx>
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: <46FC1CD4.6030905@xxxxxxxxxxxxxxx> <C3226945.E247%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
But that means you'll crash a guest that migrates from a NX-capable
machine to a  on-NX-capable machine.  (Though of course this is
detectable ahead of time, so the migration control code should just
refuse to migrate in this case.)

If we really believe that it's dangerous to let a guest see
NX-capability that doesn't really exist, perhaps we're better off
hiding NX altogether (perhaps optionally)?  I thought over that
beforehand, but it seemed kind of drastic to me, though I realize it's
a much more "pure" solution in that the guest can't see
inconsistencies due to virtualization.


On 9/28/07, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
> On 27/9/07 22:12, "David Lively" <dlively@xxxxxxxxxxxxxxx> wrote:
> > The attached patch (to 3.1.1-rc2) fixes a hypervisor crash that we're
> > seeing when migrating a HVM guest from a machine that supports the NX
> > bit to one that doesn't (e.g., because it's disabled in the BIOS).  It
> > keeps the guest copy of EFER "as is", so the guest will see EFER_NX if
> > it previously set it -- we just won't propagate this EFER bit to a
> > non-NX-capable host.
> Actually this issue is very nearly handled by xen-3.1-testing:15064 and
> xen-unstable:15066. The HVM state load code that sets guest efer should barf
> on !cpu_has_nx && EFER_NX, just as the wrmsr-handling code does.
>  -- Keir
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list