RE: [Xen-devel] Weekly VMX status report. Xen: #18846 & Xen0: #749

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

On 12/13/2008 7:40:51 AM, Keir Fraser wrote:
> On 13/12/2008 15:14, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx> wrote:
>
> > > Well, I vote for leaving EFER_NX always on then. It makes the code
> > > simpler too. Anyone against this?
> >
> > Agree. Modern VMX-capable processors can save/restore Guest/Host
> > IA32_EFER in the VMCS at VM exit/entry time, and I don't expect
> > additional overheads from that.
> >
> > So the options are:
> > 1. Enable that feature (does not help old processors, though), or 2.
> > If the guest does not enable NX but the processor does, set/reset NX
> > at VM entry/exit. We are already handling other bits (e.g. SCE).
>
> I'm not clear what your position is from the above. I should point out
> that we don't mess with EFER on vmentry/vmexit at all right now. We
> fix up EFER.SCE and other bits on context switch, but not on every entry/exit.

I misunderstood what you want to do; I thought you wanted to leaving EFER_NX 
always on in _Xen_.

>
> I think you agree that we don't need to keep guest 'actual' EFER.NX in
> sync with its 'shadow' EFER.NX?
>

That should be okay. The fact we see the NX bit in the shadow page tables means 
at least the BSP enabled NX. And I don't expect other processors would do 
otherwise. In other words, such out-of-sync situations be transient anyway.
             .
Jun Nakajima | Intel Open Source Technology Center

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel