[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH][HVM] fix migration from NX-capable machine to non-NX-capable machine
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |