Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

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/11.3.6.070618
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel