From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH v2] Enable SMEP CPU feature support for XEN hypervisor Date: Sun, 05 Jun 2011 16:10:17 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Li, Xin" , Jan Beulich Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 05/06/2011 09:39, "Li, Xin" wrote: >> I mean, I know we may as well just hide the feature from PV 64b guests >> totally. That's obvious. Let's stop talking about PV 64b guests already! The >> question is: what to do about PV 32b guests? > >> Quite obviously we ought to allow 32-bit pv guests to control this for >> themselves (and hence see the feature). > > That needs > 1) inject SMEP faults back to the 32-bit pv guest. > 2) let the guest see SMEP thru CPUID and config it in CR4 (actually it's > already set, but just to let guest see it). > > Anything else? I thought about this myself and realised that we can't let PV guests control this feature if we want Xen to benefit from it. There's little point in a feature to protect Xen from guests, if an untrusted guest can turn it off! Hence I think we probably have to leave the feature always on for PV guests. Unless we find some guests are incompatible with that. -- Keir >> Besides that, assuming Xin verified it's working, your latest patch >> looks great to me. > > Yeah, verified, the system crashed from a SMEP fault from 64-bit pv kernel. > Thanks! > -Xin