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

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

On 12/13/2008 6:06:18 AM, Keir Fraser wrote:
> On 12/12/2008 23:30, "Gianluca Guida" <gianluca.guida@xxxxxxxxxxxxx>
> wrote:
>
> > Keir Fraser wrote:
> > > Is there any guest that actually cares about having EFER_NX really
> > > cleared? Presumably the only way of detecting this would be
> > > reserved-bit page faults, which no OS is likely to want to
> > > deliberately cause?
> >
> > Yes, no OS we've actually experienced at the moment rely on reserved
> > bit faults (with the most notable exception of Tim's fast path for
> > MMIO and non present pages in Xen's shadow entries).
> > I am sure about this for a very simple reason: -- some kind of
> > secret I would like to share with you and xen-devel -- shadow code
> > doesn't check at all for reserved bits when propagating changes from
> > guest to shadows, so we never propagate reserved bit faults to
> > guests. [working on this]
>
> 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).


Thanks,
             .
Jun Nakajima | Intel Open Source Technology Center

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