Re: [Xen-devel] [PATCH v3 0/4] x86: accommodate 32-bit PV guests with SMEP/SMAP handling

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, March 17, 2016 3:51 PM
> To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Wu, Feng
> <feng.wu@xxxxxxxxx>; Keir Fraser <keir@xxxxxxx>
> Subject: [PATCH v3 0/4] x86: accommodate 32-bit PV guests with SMEP/SMAP
> handling
> 
> As has been explained previously[1], SMAP (and with less relevance
> also SMEP) is not compatible with 32-bit PV guests which aren't
> aware/prepared to be run with that feature enabled. Andrew's
> original approach either sacrificed architectural correctness for
> making 32-bit guests work again, or disabled SMAP also for not
> insignificant portions of hypervisor code, both by allowing to control
> the workaround mode via command line option.

Hi Jan, do you mind sharing more about Andrew's original approach?
And to solve this issue can we just disable SMEP/SMAP for Xen itself,
hence only HVM will benefit from this feature?

Thanks,
Feng

> 
> This alternative approach disables SMEP and SMAP only while
> running 32-bit PV guest code plus a few hypervisor instructions
> early after entering hypervisor context from or late before exiting
> to such guests. Those few instructions (in assembly source) are of
> course much easier to prove not to perform undue memory
> accesses than code paths reaching deep into C sources.
> 
> The 4th patch really is unrelated except for not applying cleanly
> without the earlier ones, and the potential having been noticed
> while putting together the 2nd one.
> 
> 1: move cached CR4 value to struct cpu_info
> 2: suppress SMEP and SMAP while running 32-bit PV guest code
> 3: use optimal NOPs to fill the SMEP/SMAP placeholders
> 4: use 32-bit loads for 32-bit PV guest state reload
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v3: New patch 1, as a prereq to changes in patch 2 (previously
>      1). The primary reason for this are performance issues that
>      have been found by Andrew with the previous version.
> v2: Various changes to patches 1 and 2 - see there.
> 
> [1] http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg03888.html


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel