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

[Jan Beulich]

>>> On 21.06.16 at 08:19,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, March 17, 2016 3:51 PM
>> 
>> 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?

Did you look at the link still visible below? If you did, please be more
precise about the details you need.

>> 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 
>> ---
>> 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

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

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, March 17, 2016 3:51 PM
> To: xen-devel 
> Cc: Andrew Cooper ; Wu, Feng
> ; Keir Fraser 
> 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 
> ---
> 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

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

[Andrew Cooper]

On 13/05/16 18:02, Wei Liu wrote:
> On Thu, Mar 17, 2016 at 01:50:39AM -0600, Jan Beulich wrote:
>> 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.
>>
>> 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 
> Release-acked-by: Wei Liu 

And applied.

~Andrew

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

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

[Wei Liu]

On Thu, Mar 17, 2016 at 01:50:39AM -0600, Jan Beulich wrote:
> 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.
> 
> 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 

Release-acked-by: Wei Liu 

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

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

[Jan Beulich]

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.

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 
---
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