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] [Patch] Enable SMEP CPU feature support for XEN itself

To: Jan Beulich <JBeulich@xxxxxxxxxx>, "Yang, Wei Y" <wei.y.yang@xxxxxxxxx>
Subject: RE: [Xen-devel] [Patch] Enable SMEP CPU feature support for XEN itself
From: "Li, Xin" <xin.li@xxxxxxxxx>
Date: Thu, 2 Jun 2011 15:45:57 +0800
Accept-language: zh-CN, en-US
Acceptlanguage: zh-CN, en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 02 Jun 2011 03:31:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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: <5D8008F58939784290FAB48F5497519844F6FB0DBA@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4DE674150200007800044EF3@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acwgb3MM+3IGgI06Tu234MSggrGCoQAYc0swAAnBpaA=
Thread-topic: [Xen-devel] [Patch] Enable SMEP CPU feature support for XEN itself
> > > +                 setup_clear_cpu_cap(X86_FEATURE_SMEP);
> > > +                 clear_in_cr4(X86_CR4_SMEP);
> > > +         } else
> > > +                 set_in_cr4(X86_CR4_SMEP);
> >
> > Anyway, the whole thing is overkill - {set,clear}_in_cr4() write
> > the updated bits to mmu_cr4_features, and these get loaded
> > on secondary CPUs *before* you have any chance of looking
> > at the CPUID bits. As with everything else, it's assumed that
> > APs don't have less features than the BP, and hence you only
> > need to set_in_cr4() once (on the BP). And then the function
> > can be __init.
> >
> 
> Do you mean?
>         if ( cpu_has(c, X86_FEATURE_SMEP) )
>                 if( likely(!disable_smep) ) {
>                         mmu_cr4_features |= X86_CR4_SMEP;
>                         set_in_cr4(0);
>                 } else
>                         setup_clear_cpu_cap(X86_FEATURE_SMEP);
> 
> Sounds good ... but the code will be harder to read, as it implicitly set 
> smep?
> Also where to put setup_smep thus it's only called in BP?
> 
But it is a good idea to set X86_CR4_SMEP in mmu_cr4_features when SMEP
Is available.  thus

1) for PV, we can make patch like pv_guest_cr4_to_real_cr4
#define pv_guest_cr4_to_real_cr4(v)                         \
    (((v)->arch.pv_vcpu.ctrlreg[4]                          \
      | (mmu_cr4_features & (X86_CR4_PGE | X86_CR4_PSE | X86_CR4_SMEP))    \
      | ((v)->domain->arch.vtsc ? X86_CR4_TSD : 0)          \
      | ((xsave_enabled(v))? X86_CR4_OSXSAVE : 0))          \
      & ~X86_CR4_DE)
when set cr4.

2) For HVM, we don't need to explicitly add SMEP when write to HOST_CR4.

Thanks!
-Xin

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