WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Weekly VMX status report. Xen: #18846 & Xen0: #749
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Sat, 13 Dec 2008 14:43:07 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Li, Haicheng" <haicheng.li@xxxxxxxxx>, "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>
Delivery-date: Sat, 13 Dec 2008 14:43:40 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5698803.20365%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <0B53E02A2965CE4F9ADB38B34501A3A16825BA3F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C5698803.20365%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcldK/fZZNTFfVr6k0WK9hRQshPOTwAAZfOQAALnZR0ADcmHgA==
Thread-topic: [Xen-devel] Weekly VMX status report. Xen: #18846 & Xen0: #749
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

<Prev in Thread] Current Thread [Next in Thread>