Re: [Xen-devel] [PATCH][HVM] fix migration from NX-capable machine to non-NX-capable machine

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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