Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

2018-02-14 Thread Jan Beulich 
>>> On 12.02.18 at 12:23,  wrote:
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -109,13 +109,10 @@ ENTRY(compat_restore_all_guest)
>  ASSERT_INTERRUPTS_DISABLED
>  mov   $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),%r11d
>  and   UREGS_eflags(%rsp),%r11d
> -.Lcr4_orig:
> -.skip .Lcr4_alt_end - .Lcr4_alt, 0x90
> -.Lcr4_orig_end:
> -.pushsection .altinstr_replacement, "ax"
> -.Lcr4_alt:
> +
> +.macro alt_cr4_pv32
>  testb $3,UREGS_cs(%rsp)
> -jpe   .Lcr4_alt_end
> +jpe   2f
>  mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
>  and   $~XEN_CR4_PV32_BITS, %rax
>  1:
> @@ -133,17 +130,12 @@ ENTRY(compat_restore_all_guest)
>   */
>  cmp   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
>  jne   1b
> -.Lcr4_alt_end:
> -.section .altinstructions, "a"
> -altinstruction_entry .Lcr4_orig, .Lcr4_orig, X86_FEATURE_ALWAYS, \
> - (.Lcr4_orig_end - .Lcr4_orig), 0
> -altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_XEN_SMEP, \
> - (.Lcr4_orig_end - .Lcr4_orig), \
> - (.Lcr4_alt_end - .Lcr4_alt)
> -altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_XEN_SMAP, \
> - (.Lcr4_orig_end - .Lcr4_orig), \
> - (.Lcr4_alt_end - .Lcr4_alt)
> -.popsection
> +2:
> +.endm
> + ALTERNATIVE_2 ".skip 45, 0x90", \
> +alt_cr4_pv32, X86_FEATURE_XEN_SMEP, \
> +alt_cr4_pv32, X86_FEATURE_XEN_SMAP

I'm not particularly in favor of this, but considering the end result
(after patch 6) it looks reasonable to accept the code duplication.
Down the road we may want to think about ways to re-use
replacement code sequences when they're identical.

Reviewed-by: Jan Beulich 



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

2018-02-13 Thread Jan Beulich 
>>> On 13.02.18 at 11:07,  wrote:
> On 13/02/2018 09:56, Jan Beulich wrote:
> On 12.02.18 at 13:30,  wrote:
>>> On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote:
 diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
 index 58f652d..bd3819a 100644
 --- a/xen/arch/x86/x86_64/entry.S
 +++ b/xen/arch/x86/x86_64/entry.S
 @@ -557,23 +557,9 @@ handle_exception_saved:
  testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
  jzexception_with_ints_disabled
  
 -.Lcr4_pv32_orig:
 -jmp   .Lcr4_pv32_done
 -.skip (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt) - (. - 
 .Lcr4_pv32_orig), 0xcc
 -.pushsection .altinstr_replacement, "ax"
 -.Lcr4_pv32_alt:
 -mov   VCPU_domain(%rbx),%rax
 -.Lcr4_pv32_alt_end:
 -.section .altinstructions, "a"
 -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
 - X86_FEATURE_XEN_SMEP, \
 - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
 - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
 -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
 - X86_FEATURE_XEN_SMAP, \
 - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
 - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
 -.popsection
 +ALTERNATIVE_2 "jmp .Lcr4_pv32_done; .skip 2, 0x90", \
>>> This changed 0xcc to 0x90 but since it is just padding following an
>>> unconditional jmp so it shouldn't matter.
>> Well, it was for that very reason that I had picked 0xcc originally:
>> We better know if some branch mistakenly leads into that region.
> 
> Know how?  At the time you wrote this, Xen silently executed its way
> through debug traps, and it took some persuading to get you to ok the
> patch which at least printed a line every time we a breakpoint in
> hypervisor space.

Granted I didn't realize at the time that breakpoints would go all
silent.

> If you actually want to notice going down the wrong path, then you want
> a BUG.

I'd be very much in favor of this, if only there was a single byte insn
documented to cause #UD now and forever. Abusing what is INTO or
SALC outside of 64-bit mode doesn't look very attractive.

>> I also very much object to the literal 2 passed as an argument to
>> .skip above: What if the label moves out far enough that a short
>> branch won't be usable anymore?
> 
> Is the commit message not enough?  a) its not going to change, because
> it hasn't changed since you put the code in originally and I don't
> expect it to in the future, and b) it is a temporary necessary
> requirement to make the series bisectable and reviewable.  This skip is
> dropped in patch 6 when the automatic padding calculations work.

Oh, if it goes away by the end of the series, then that's fine.
(When replying here I hadn't looked at the full patch yet, so please
accept my apologies if this is properly explained in the description.)

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

2018-02-13 Thread Andrew Cooper 
On 13/02/2018 09:56, Jan Beulich wrote:
 On 12.02.18 at 13:30,  wrote:
>> On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote:
>>> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
>>> index 58f652d..bd3819a 100644
>>> --- a/xen/arch/x86/x86_64/entry.S
>>> +++ b/xen/arch/x86/x86_64/entry.S
>>> @@ -557,23 +557,9 @@ handle_exception_saved:
>>>  testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
>>>  jzexception_with_ints_disabled
>>>  
>>> -.Lcr4_pv32_orig:
>>> -jmp   .Lcr4_pv32_done
>>> -.skip (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt) - (. - 
>>> .Lcr4_pv32_orig), 0xcc
>>> -.pushsection .altinstr_replacement, "ax"
>>> -.Lcr4_pv32_alt:
>>> -mov   VCPU_domain(%rbx),%rax
>>> -.Lcr4_pv32_alt_end:
>>> -.section .altinstructions, "a"
>>> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
>>> - X86_FEATURE_XEN_SMEP, \
>>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
>>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
>>> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
>>> - X86_FEATURE_XEN_SMAP, \
>>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
>>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
>>> -.popsection
>>> +ALTERNATIVE_2 "jmp .Lcr4_pv32_done; .skip 2, 0x90", \
>> This changed 0xcc to 0x90 but since it is just padding following an
>> unconditional jmp so it shouldn't matter.
> Well, it was for that very reason that I had picked 0xcc originally:
> We better know if some branch mistakenly leads into that region.

Know how?  At the time you wrote this, Xen silently executed its way
through debug traps, and it took some persuading to get you to ok the
patch which at least printed a line every time we a breakpoint in
hypervisor space.

If you actually want to notice going down the wrong path, then you want
a BUG.

> I also very much object to the literal 2 passed as an argument to
> .skip above: What if the label moves out far enough that a short
> branch won't be usable anymore?

Is the commit message not enough?  a) its not going to change, because
it hasn't changed since you put the code in originally and I don't
expect it to in the future, and b) it is a temporary necessary
requirement to make the series bisectable and reviewable.  This skip is
dropped in patch 6 when the automatic padding calculations work.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

2018-02-13 Thread Jan Beulich 
>>> On 12.02.18 at 13:30,  wrote:
> On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
>> index 58f652d..bd3819a 100644
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -557,23 +557,9 @@ handle_exception_saved:
>>  testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
>>  jzexception_with_ints_disabled
>>  
>> -.Lcr4_pv32_orig:
>> -jmp   .Lcr4_pv32_done
>> -.skip (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt) - (. - 
>> .Lcr4_pv32_orig), 0xcc
>> -.pushsection .altinstr_replacement, "ax"
>> -.Lcr4_pv32_alt:
>> -mov   VCPU_domain(%rbx),%rax
>> -.Lcr4_pv32_alt_end:
>> -.section .altinstructions, "a"
>> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
>> - X86_FEATURE_XEN_SMEP, \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
>> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
>> - X86_FEATURE_XEN_SMAP, \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
>> -.popsection
>> +ALTERNATIVE_2 "jmp .Lcr4_pv32_done; .skip 2, 0x90", \
> 
> This changed 0xcc to 0x90 but since it is just padding following an
> unconditional jmp so it shouldn't matter.

Well, it was for that very reason that I had picked 0xcc originally:
We better know if some branch mistakenly leads into that region.

I also very much object to the literal 2 passed as an argument to
.skip above: What if the label moves out far enough that a short
branch won't be usable anymore?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

2018-02-12 Thread Roger Pau Monné 
On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote:
> With future changes, altinstruction_entry is going to become more complicated
> to use.  Furthermore, there are already ALTERNATIVE* macros which can be used
> to avoid opencoding the creation of replacement information.
> 
> For ASM_STAC, ASM_CLAC and CR4_PV32_RESTORE, this means the removal of all
> hardocded label numbers.  For the cr4_pv32 alternatives, this means hardcoding
> the extra space required in the original patch site, but the hardcoding will
> be removed by a later patch.
> 
> No change to any functionality, but the handling of nops inside the original
> patch sites are a bit different.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

In general I try to align the line breaks '\' of macros, but I don't
think that's used consistently across the code at all.

Again just one nit below.

> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
> index 58f652d..bd3819a 100644
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -557,23 +557,9 @@ handle_exception_saved:
>  testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
>  jzexception_with_ints_disabled
>  
> -.Lcr4_pv32_orig:
> -jmp   .Lcr4_pv32_done
> -.skip (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt) - (. - .Lcr4_pv32_orig), 
> 0xcc
> -.pushsection .altinstr_replacement, "ax"
> -.Lcr4_pv32_alt:
> -mov   VCPU_domain(%rbx),%rax
> -.Lcr4_pv32_alt_end:
> -.section .altinstructions, "a"
> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
> - X86_FEATURE_XEN_SMEP, \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
> - X86_FEATURE_XEN_SMAP, \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
> -.popsection
> +ALTERNATIVE_2 "jmp .Lcr4_pv32_done; .skip 2, 0x90", \
> +__stringify(mov VCPU_domain(%rbx), %rax), X86_FEATURE_XEN_SMEP, \
> +__stringify(mov VCPU_domain(%rbx), %rax), X86_FEATURE_XEN_SMAP

What's the point of using __stringify here, isn't it clearer to just
use "mov ..."?

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

2018-02-12 Thread Wei Liu 
On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote:
> With future changes, altinstruction_entry is going to become more complicated
> to use.  Furthermore, there are already ALTERNATIVE* macros which can be used
> to avoid opencoding the creation of replacement information.
> 
> For ASM_STAC, ASM_CLAC and CR4_PV32_RESTORE, this means the removal of all
> hardocded label numbers.  For the cr4_pv32 alternatives, this means hardcoding
> the extra space required in the original patch site, but the hardcoding will
> be removed by a later patch.
> 
> No change to any functionality, but the handling of nops inside the original
> patch sites are a bit different.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

2018-02-12 Thread Andrew Cooper 
On 12/02/18 12:30, Wei Liu wrote:
> On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
>> index 58f652d..bd3819a 100644
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -557,23 +557,9 @@ handle_exception_saved:
>>  testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
>>  jzexception_with_ints_disabled
>>  
>> -.Lcr4_pv32_orig:
>> -jmp   .Lcr4_pv32_done
>> -.skip (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt) - (. - 
>> .Lcr4_pv32_orig), 0xcc
>> -.pushsection .altinstr_replacement, "ax"
>> -.Lcr4_pv32_alt:
>> -mov   VCPU_domain(%rbx),%rax
>> -.Lcr4_pv32_alt_end:
>> -.section .altinstructions, "a"
>> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
>> - X86_FEATURE_XEN_SMEP, \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
>> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
>> - X86_FEATURE_XEN_SMAP, \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
>> -.popsection
>> +ALTERNATIVE_2 "jmp .Lcr4_pv32_done; .skip 2, 0x90", \
> This changed 0xcc to 0x90 but since it is just padding following an
> unconditional jmp so it shouldn't matter.
>
> Mostly looks fine. I'm a bit hesitant to give my Rb because reviewing
> the diff to assembly is a bit more difficult to than diff to C source.
>
> Do you have a branch somewhere?

http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/alternatives-v1

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

2018-02-12 Thread Wei Liu 
On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
> index 58f652d..bd3819a 100644
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -557,23 +557,9 @@ handle_exception_saved:
>  testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
>  jzexception_with_ints_disabled
>  
> -.Lcr4_pv32_orig:
> -jmp   .Lcr4_pv32_done
> -.skip (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt) - (. - .Lcr4_pv32_orig), 
> 0xcc
> -.pushsection .altinstr_replacement, "ax"
> -.Lcr4_pv32_alt:
> -mov   VCPU_domain(%rbx),%rax
> -.Lcr4_pv32_alt_end:
> -.section .altinstructions, "a"
> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
> - X86_FEATURE_XEN_SMEP, \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
> - X86_FEATURE_XEN_SMAP, \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
> -.popsection
> +ALTERNATIVE_2 "jmp .Lcr4_pv32_done; .skip 2, 0x90", \

This changed 0xcc to 0x90 but since it is just padding following an
unconditional jmp so it shouldn't matter.

Mostly looks fine. I'm a bit hesitant to give my Rb because reviewing
the diff to assembly is a bit more difficult to than diff to C source.

Do you have a branch somewhere?

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

2018-02-12 Thread Andrew Cooper 
With future changes, altinstruction_entry is going to become more complicated
to use.  Furthermore, there are already ALTERNATIVE* macros which can be used
to avoid opencoding the creation of replacement information.

For ASM_STAC, ASM_CLAC and CR4_PV32_RESTORE, this means the removal of all
hardocded label numbers.  For the cr4_pv32 alternatives, this means hardcoding
the extra space required in the original patch site, but the hardcoding will
be removed by a later patch.

No change to any functionality, but the handling of nops inside the original
patch sites are a bit different.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Roger Pau Monné 
CC: Wei Liu 
---
 xen/arch/x86/x86_64/compat/entry.S | 26 +-
 xen/arch/x86/x86_64/entry.S| 20 +++-
 xen/include/asm-x86/asm_defns.h| 32 +++-
 3 files changed, 23 insertions(+), 55 deletions(-)

diff --git a/xen/arch/x86/x86_64/compat/entry.S 
b/xen/arch/x86/x86_64/compat/entry.S
index 707c746..e93770f 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -109,13 +109,10 @@ ENTRY(compat_restore_all_guest)
 ASSERT_INTERRUPTS_DISABLED
 mov   $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),%r11d
 and   UREGS_eflags(%rsp),%r11d
-.Lcr4_orig:
-.skip .Lcr4_alt_end - .Lcr4_alt, 0x90
-.Lcr4_orig_end:
-.pushsection .altinstr_replacement, "ax"
-.Lcr4_alt:
+
+.macro alt_cr4_pv32
 testb $3,UREGS_cs(%rsp)
-jpe   .Lcr4_alt_end
+jpe   2f
 mov   CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp), %rax
 and   $~XEN_CR4_PV32_BITS, %rax
 1:
@@ -133,17 +130,12 @@ ENTRY(compat_restore_all_guest)
  */
 cmp   %rax, CPUINFO_cr4-CPUINFO_guest_cpu_user_regs(%rsp)
 jne   1b
-.Lcr4_alt_end:
-.section .altinstructions, "a"
-altinstruction_entry .Lcr4_orig, .Lcr4_orig, X86_FEATURE_ALWAYS, \
- (.Lcr4_orig_end - .Lcr4_orig), 0
-altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_XEN_SMEP, \
- (.Lcr4_orig_end - .Lcr4_orig), \
- (.Lcr4_alt_end - .Lcr4_alt)
-altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_XEN_SMAP, \
- (.Lcr4_orig_end - .Lcr4_orig), \
- (.Lcr4_alt_end - .Lcr4_alt)
-.popsection
+2:
+.endm
+   ALTERNATIVE_2 ".skip 45, 0x90", \
+alt_cr4_pv32, X86_FEATURE_XEN_SMEP, \
+alt_cr4_pv32, X86_FEATURE_XEN_SMAP
+
 or$X86_EFLAGS_IF,%r11
 mov   %r11d,UREGS_eflags(%rsp)
 
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 58f652d..bd3819a 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -557,23 +557,9 @@ handle_exception_saved:
 testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
 jzexception_with_ints_disabled
 
-.Lcr4_pv32_orig:
-jmp   .Lcr4_pv32_done
-.skip (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt) - (. - .Lcr4_pv32_orig), 
0xcc
-.pushsection .altinstr_replacement, "ax"
-.Lcr4_pv32_alt:
-mov   VCPU_domain(%rbx),%rax
-.Lcr4_pv32_alt_end:
-.section .altinstructions, "a"
-altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
- X86_FEATURE_XEN_SMEP, \
- (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
- (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
-altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
- X86_FEATURE_XEN_SMAP, \
- (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
- (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
-.popsection
+ALTERNATIVE_2 "jmp .Lcr4_pv32_done; .skip 2, 0x90", \
+__stringify(mov VCPU_domain(%rbx), %rax), X86_FEATURE_XEN_SMEP, \
+__stringify(mov VCPU_domain(%rbx), %rax), X86_FEATURE_XEN_SMAP
 
 testb $3,UREGS_cs(%rsp)
 jz.Lcr4_pv32_done
diff --git a/xen/include/asm-x86/asm_defns.h b/xen/include/asm-x86/asm_defns.h
index aee14ba..b9140de 100644
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -192,18 +192,13 @@ void ret_from_intr(void);
 #define __ASM_STAC  .byte 0x0f,0x01,0xcb
 
 #ifdef __ASSEMBLY__
-#define ASM_AC(op) \
-661: ASM_NOP3; \
-.pushsection .altinstr_replacement, "ax";  \
-662: __ASM_##op;   \
-.popsection;   \
-.pushsection .altinstructions, "a";