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: Dave Lively <dlively@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][HVM] fix migration from NX-capable machine to non-NX-capable machine
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 28 Sep 2007 15:01:04 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 28 Sep 2007 07:02:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1b64e7ec0709280623i7c7a6a74q2d33dd5fef3ed214@xxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcgB2AIbQOZau23LEdykXwAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH][HVM] fix migration from NX-capable machine to non-NX-capable machine
User-agent: Microsoft-Entourage/
Well, either we should consistently silently mask NX, or we should
consistently fail on it. Currently the code mostly does the latter. And I
think that makes most sense, and what we're looking at here is a lack of
CPUID configurability. I'd rather see patches to fix that, so that NX is
consistently hidden, according to user preference.

 -- Keir

On 28/9/07 14:23, "Dave Lively" <dlively@xxxxxxxxxxxxxxx> wrote:

> 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.
> Dave
> 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