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

["Dave Lively" <dlively@xxxxxxxxxxxxxxx>]

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