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 18:04:06 +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 16:43, "Li, Xin" wrote: >>> 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. > > As we talked, 64-bit pv kernel can't trigger SMEP faults. So we decided to not > let it see this feature. Yes, we're talking about 32b guests here. > Maybe it's okay to inject SMEP faults which are triggered from 32-bit pv > kernel back to it even the guest is not aware of SMEP. We don't really have a choice about it, if SMEP is enabled. We don't usually call spurious_page_fault() for guest faults. And as I said, we can't allow a 32b PV guest to disable SMEP, as SMEP is protecting Xen too. > We can refer to Linux SMEP patch, which just turns this feature on without > touching any page table handling functions as SMEP handling actually can > reuse NX handling code path. Yeah, most likely we can turn this on for PV guests, without them really knowing about it, and nothing will break. > Ingo wanted to expose SMEP to KVM guest > silently, but it is not architecturally right as it's required to flush TLB > when > CR4.SMEP is changed, or a kernel page is changed to user page. But luckily > Linux doesn't have such cases thus doesn't need to flush TLB. HVM guests are a separate matter and we will want to make SMEP properly configurable by the guest, as I believe your current patch proposes. -- Keir > Thanks! > -Xin