> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, March 17, 2016 3:51 PM > To: xen-devel <xen-de...@lists.xenproject.org> > Cc: Andrew Cooper <andrew.coop...@citrix.com>; Wu, Feng > <feng...@intel.com>; Keir Fraser <k...@xen.org> > 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 <jbeul...@suse.com> > --- > 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@lists.xen.org http://lists.xen.org/xen-devel
