From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Weekly VMX status report. Xen: #18846 & Xen0: #749 Date: Sat, 13 Dec 2008 14:06:18 +0000 Message-ID: References: <4942F41D.6060702@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4942F41D.6060702@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gianluca Guida Cc: "Li, Haicheng" , "'xen-devel@lists.xensource.com'" , "Li, Xin" List-Id: xen-devel@lists.xenproject.org On 12/12/2008 23:30, "Gianluca Guida" 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? -- Keir