* [PATCH v3 0/5] x86: Use alternative mechanism to define CLAC/STAC
@ 2014-05-30 8:56 Feng Wu
2014-05-30 8:56 ` [PATCH v3 1/5] Use __stringify() as the only method for performing preprocessor stringificaion Feng Wu
` (4 more replies)
0 siblings, 5 replies; 21+ messages in thread
From: Feng Wu @ 2014-05-30 8:56 UTC (permalink / raw)
To: xen-devel
Cc: Feng Wu, ian.campbell, andrew.cooper3, tim, keir.xen,
stefano.stabellini, JBeulich, boris.ostrovsky
This patch set ports the basic alternative mechanism from Linux to Xen
and use it to define CLAC/STAC.
Version 1:
* Initial version.
Version 2:
* Use STR() as the only method for performing preprocessor stringificaion.
* Set ideal_nops to k8_nops by default.
* Make ideal_nops static and __initdata.
* Mask the lowest bit when handling relative jump in apply_alternatives().
* Move .altinstr_replacemen and altinstructions to .init section.
* Include nops.h in alternative.h.
* Some code style changes.
Version 3:
* Use __stringify() instead of STR().
* Coding style changes.
* Add ASSERT(!local_irq_is_enabled()) in the beginning of apply_alternatives().
* Remove local_irq_save()/local_irq_restore() in text_poke_early().
There are some changes related to ARM and AMD code in the first patch of this
series, but I don't have ARM and AMD environment to verify it. The changes in
Intel platform side have the same logic, and I verify it in Intel side.
Feng Wu (5):
Use __stringify() as the only method for performing preprocessor
stringificaion
x86: Add definitions for NOP operation
x86: Make set_nmi_callback return the old nmi callback
x86: Port the basic alternative mechanism from Linux to Xen
x86: Use alternative mechanism to define CLAC/STAC
xen/arch/x86/Makefile | 1 +
xen/arch/x86/alternative.c | 213 ++++++++++++++++++++++++++++++++++++++
xen/arch/x86/bitops.c | 9 +-
xen/arch/x86/hvm/svm/svm.c | 2 +-
xen/arch/x86/setup.c | 3 +
xen/arch/x86/traps.c | 4 +-
xen/arch/x86/usercopy.c | 20 ++--
xen/arch/x86/xen.lds.S | 15 +++
xen/include/asm-arm/current.h | 4 +-
xen/include/asm-x86/alternative.h | 78 ++++++++++++++
xen/include/asm-x86/asm_defns.h | 23 ++--
xen/include/asm-x86/multicall.h | 115 ++++++++++----------
xen/include/asm-x86/nmi.h | 4 +-
xen/include/asm-x86/nops.h | 66 ++++++++++++
xen/include/asm-x86/system.h | 9 +-
xen/include/xen/config.h | 3 -
16 files changed, 475 insertions(+), 94 deletions(-)
create mode 100644 xen/arch/x86/alternative.c
create mode 100644 xen/include/asm-x86/alternative.h
create mode 100644 xen/include/asm-x86/nops.h
--
1.8.3.1
^ permalink raw reply [flat|nested] 21+ messages in thread* [PATCH v3 1/5] Use __stringify() as the only method for performing preprocessor stringificaion 2014-05-30 8:56 [PATCH v3 0/5] x86: Use alternative mechanism to define CLAC/STAC Feng Wu @ 2014-05-30 8:56 ` Feng Wu 2014-05-30 11:35 ` Jan Beulich 2014-05-30 8:56 ` [PATCH v3 2/5] x86: Add definitions for NOP operation Feng Wu ` (3 subsequent siblings) 4 siblings, 1 reply; 21+ messages in thread From: Feng Wu @ 2014-05-30 8:56 UTC (permalink / raw) To: xen-devel Cc: Feng Wu, ian.campbell, andrew.cooper3, tim, keir.xen, stefano.stabellini, JBeulich, boris.ostrovsky There are two ways of performing preprocessor stringificaion in the current code: __stringify() from stringify.h, and STR() from config.h. This patch consolidates down to one. Signed-off-by: Feng Wu <feng.wu@intel.com> --- xen/arch/x86/bitops.c | 9 ++-- xen/arch/x86/hvm/svm/svm.c | 2 +- xen/arch/x86/usercopy.c | 20 +++---- xen/include/asm-arm/current.h | 4 +- xen/include/asm-x86/multicall.h | 115 ++++++++++++++++++++-------------------- xen/include/asm-x86/system.h | 9 ++-- xen/include/xen/config.h | 3 -- 7 files changed, 81 insertions(+), 81 deletions(-) diff --git a/xen/arch/x86/bitops.c b/xen/arch/x86/bitops.c index c037567..824a9d6 100644 --- a/xen/arch/x86/bitops.c +++ b/xen/arch/x86/bitops.c @@ -1,6 +1,7 @@ #include <xen/bitops.h> #include <xen/lib.h> +#include <xen/stringify.h> unsigned int __find_first_bit( const unsigned long *addr, unsigned int size) @@ -11,9 +12,9 @@ unsigned int __find_first_bit( "1: xor %%eax,%%eax\n\t" /* also ensures ZF==1 if size==0 */ " repe; scas"__OS"\n\t" " je 2f\n\t" - " bsf -"STR(BITS_PER_LONG/8)"(%2),%0\n\t" + " bsf -"__stringify(BITS_PER_LONG/8)"(%2),%0\n\t" " jz 1b\n\t" - " lea -"STR(BITS_PER_LONG/8)"(%2),%2\n\t" + " lea -"__stringify(BITS_PER_LONG/8)"(%2),%2\n\t" "2: sub %%ebx,%%edi\n\t" " shl $3,%%edi\n\t" " add %%edi,%%eax" @@ -60,10 +61,10 @@ unsigned int __find_first_zero_bit( " xor %%edx,%%edx\n\t" /* also ensures ZF==1 if size==0 */ " repe; scas"__OS"\n\t" " je 2f\n\t" - " xor -"STR(BITS_PER_LONG/8)"(%2),%3\n\t" + " xor -"__stringify(BITS_PER_LONG/8)"(%2),%3\n\t" " jz 1b\n\t" " bsf %3,%0\n\t" - " lea -"STR(BITS_PER_LONG/8)"(%2),%2\n\t" + " lea -"__stringify(BITS_PER_LONG/8)"(%2),%2\n\t" "2: sub %%ebx,%%edi\n\t" " shl $3,%%edi\n\t" " add %%edi,%%edx" diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 870e4ee..16b0d6d 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -72,7 +72,7 @@ u32 svm_feature_flags; bool_t cpu_has_lmsl; #define set_segment_register(name, value) \ - asm volatile ( "movw %%ax ,%%" STR(name) "" : : "a" (value) ) + asm volatile ( "movw %%ax ,%%" __stringify(name) "" : : "a" (value) ) static void svm_update_guest_efer(struct vcpu *); diff --git a/xen/arch/x86/usercopy.c b/xen/arch/x86/usercopy.c index 4cc78f5..9af9771 100644 --- a/xen/arch/x86/usercopy.c +++ b/xen/arch/x86/usercopy.c @@ -16,16 +16,16 @@ unsigned long __copy_to_user_ll(void __user *to, const void *from, unsigned n) stac(); asm volatile ( - " cmp $"STR(2*BYTES_PER_LONG-1)",%0\n" + " cmp $"__stringify(2*BYTES_PER_LONG-1)",%0\n" " jbe 1f\n" " mov %1,%0\n" " neg %0\n" - " and $"STR(BYTES_PER_LONG-1)",%0\n" + " and $"__stringify(BYTES_PER_LONG-1)",%0\n" " sub %0,%3\n" "4: rep movsb\n" /* make 'to' address aligned */ " mov %3,%0\n" - " shr $"STR(LONG_BYTEORDER)",%0\n" - " and $"STR(BYTES_PER_LONG-1)",%3\n" + " shr $"__stringify(LONG_BYTEORDER)",%0\n" + " and $"__stringify(BYTES_PER_LONG-1)",%3\n" " .align 2,0x90\n" "0: rep movs"__OS"\n" /* as many words as possible... */ " mov %3,%0\n" @@ -34,7 +34,7 @@ unsigned long __copy_to_user_ll(void __user *to, const void *from, unsigned n) ".section .fixup,\"ax\"\n" "5: add %3,%0\n" " jmp 2b\n" - "3: lea 0(%3,%0,"STR(BYTES_PER_LONG)"),%0\n" + "3: lea 0(%3,%0,"__stringify(BYTES_PER_LONG)"),%0\n" " jmp 2b\n" ".previous\n" _ASM_EXTABLE(4b, 5b) @@ -55,16 +55,16 @@ __copy_from_user_ll(void *to, const void __user *from, unsigned n) stac(); asm volatile ( - " cmp $"STR(2*BYTES_PER_LONG-1)",%0\n" + " cmp $"__stringify(2*BYTES_PER_LONG-1)",%0\n" " jbe 1f\n" " mov %1,%0\n" " neg %0\n" - " and $"STR(BYTES_PER_LONG-1)",%0\n" + " and $"__stringify(BYTES_PER_LONG-1)",%0\n" " sub %0,%3\n" "4: rep; movsb\n" /* make 'to' address aligned */ " mov %3,%0\n" - " shr $"STR(LONG_BYTEORDER)",%0\n" - " and $"STR(BYTES_PER_LONG-1)",%3\n" + " shr $"__stringify(LONG_BYTEORDER)",%0\n" + " and $"__stringify(BYTES_PER_LONG-1)",%3\n" " .align 2,0x90\n" "0: rep; movs"__OS"\n" /* as many words as possible... */ " mov %3,%0\n" @@ -73,7 +73,7 @@ __copy_from_user_ll(void *to, const void __user *from, unsigned n) ".section .fixup,\"ax\"\n" "5: add %3,%0\n" " jmp 6f\n" - "3: lea 0(%3,%0,"STR(BYTES_PER_LONG)"),%0\n" + "3: lea 0(%3,%0,"__stringify(BYTES_PER_LONG)"),%0\n" "6: push %0\n" " push %%"__OP"ax\n" " xor %%eax,%%eax\n" diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h index 65c0cdf..f4d5b61 100644 --- a/xen/include/asm-arm/current.h +++ b/xen/include/asm-arm/current.h @@ -1,12 +1,12 @@ #ifndef __ARM_CURRENT_H__ #define __ARM_CURRENT_H__ -#include <xen/config.h> #include <xen/percpu.h> #include <public/xen.h> #include <asm/percpu.h> #include <asm/processor.h> +#include <xen/stringify.h> #ifndef __ASSEMBLY__ @@ -34,7 +34,7 @@ static inline struct cpu_info *get_cpu_info(void) #define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs) #define switch_stack_and_jump(stack, fn) \ - asm volatile ("mov sp,%0; b " STR(fn) : : "r" (stack) : "memory" ) + asm volatile ("mov sp,%0; b " __stringify(fn) : : "r" (stack) : "memory" ) #define reset_stack_and_jump(fn) switch_stack_and_jump(get_cpu_info(), fn) diff --git a/xen/include/asm-x86/multicall.h b/xen/include/asm-x86/multicall.h index a09ac5a..3b414ef 100644 --- a/xen/include/asm-x86/multicall.h +++ b/xen/include/asm-x86/multicall.h @@ -6,65 +6,66 @@ #define __ASM_X86_MULTICALL_H__ #include <xen/errno.h> +#include <xen/stringify.h> -#define do_multicall_call(_call) \ - do { \ - __asm__ __volatile__ ( \ - " movq %c1(%0),%%rax; " \ - " leaq hypercall_table(%%rip),%%rdi; " \ - " cmpq $("STR(NR_hypercalls)"),%%rax; " \ - " jae 2f; " \ - " movq (%%rdi,%%rax,8),%%rax; " \ - " movq %c2+0*%c3(%0),%%rdi; " \ - " movq %c2+1*%c3(%0),%%rsi; " \ - " movq %c2+2*%c3(%0),%%rdx; " \ - " movq %c2+3*%c3(%0),%%rcx; " \ - " movq %c2+4*%c3(%0),%%r8; " \ - " movq %c2+5*%c3(%0),%%r9; " \ - " callq *%%rax; " \ - "1: movq %%rax,%c4(%0)\n" \ - ".section .fixup,\"ax\"\n" \ - "2: movq $-"STR(ENOSYS)",%%rax\n" \ - " jmp 1b\n" \ - ".previous\n" \ - : \ - : "b" (_call), \ - "i" (offsetof(__typeof__(*_call), op)), \ - "i" (offsetof(__typeof__(*_call), args)), \ - "i" (sizeof(*(_call)->args)), \ - "i" (offsetof(__typeof__(*_call), result)) \ - /* all the caller-saves registers */ \ - : "rax", "rcx", "rdx", "rsi", "rdi", \ - "r8", "r9", "r10", "r11" ); \ +#define do_multicall_call(_call) \ + do { \ + __asm__ __volatile__ ( \ + " movq %c1(%0),%%rax; " \ + " leaq hypercall_table(%%rip),%%rdi; " \ + " cmpq $("__stringify(NR_hypercalls)"),%%rax; " \ + " jae 2f; " \ + " movq (%%rdi,%%rax,8),%%rax; " \ + " movq %c2+0*%c3(%0),%%rdi; " \ + " movq %c2+1*%c3(%0),%%rsi; " \ + " movq %c2+2*%c3(%0),%%rdx; " \ + " movq %c2+3*%c3(%0),%%rcx; " \ + " movq %c2+4*%c3(%0),%%r8; " \ + " movq %c2+5*%c3(%0),%%r9; " \ + " callq *%%rax; " \ + "1: movq %%rax,%c4(%0)\n" \ + ".section .fixup,\"ax\"\n" \ + "2: movq $-"__stringify(ENOSYS)",%%rax\n" \ + " jmp 1b\n" \ + ".previous\n" \ + : \ + : "b" (_call), \ + "i" (offsetof(__typeof__(*_call), op)), \ + "i" (offsetof(__typeof__(*_call), args)), \ + "i" (sizeof(*(_call)->args)), \ + "i" (offsetof(__typeof__(*_call), result)) \ + /* all the caller-saves registers */ \ + : "rax", "rcx", "rdx", "rsi", "rdi", \ + "r8", "r9", "r10", "r11" ); \ } while ( 0 ) -#define compat_multicall_call(_call) \ - __asm__ __volatile__ ( \ - " movl %c1(%0),%%eax; " \ - " leaq compat_hypercall_table(%%rip),%%rdi; "\ - " cmpl $("STR(NR_hypercalls)"),%%eax; " \ - " jae 2f; " \ - " movq (%%rdi,%%rax,8),%%rax; " \ - " movl %c2+0*%c3(%0),%%edi; " \ - " movl %c2+1*%c3(%0),%%esi; " \ - " movl %c2+2*%c3(%0),%%edx; " \ - " movl %c2+3*%c3(%0),%%ecx; " \ - " movl %c2+4*%c3(%0),%%r8d; " \ - " movl %c2+5*%c3(%0),%%r9d; " \ - " callq *%%rax; " \ - "1: movl %%eax,%c4(%0)\n" \ - ".section .fixup,\"ax\"\n" \ - "2: movl $-"STR(ENOSYS)",%%eax\n" \ - " jmp 1b\n" \ - ".previous\n" \ - : \ - : "b" (_call), \ - "i" (offsetof(__typeof__(*_call), op)), \ - "i" (offsetof(__typeof__(*_call), args)), \ - "i" (sizeof(*(_call)->args)), \ - "i" (offsetof(__typeof__(*_call), result)) \ - /* all the caller-saves registers */ \ - : "rax", "rcx", "rdx", "rsi", "rdi", \ - "r8", "r9", "r10", "r11" ) \ +#define compat_multicall_call(_call) \ + __asm__ __volatile__ ( \ + " movl %c1(%0),%%eax; " \ + " leaq compat_hypercall_table(%%rip),%%rdi; " \ + " cmpl $("__stringify(NR_hypercalls)"),%%eax; " \ + " jae 2f; " \ + " movq (%%rdi,%%rax,8),%%rax; " \ + " movl %c2+0*%c3(%0),%%edi; " \ + " movl %c2+1*%c3(%0),%%esi; " \ + " movl %c2+2*%c3(%0),%%edx; " \ + " movl %c2+3*%c3(%0),%%ecx; " \ + " movl %c2+4*%c3(%0),%%r8d; " \ + " movl %c2+5*%c3(%0),%%r9d; " \ + " callq *%%rax; " \ + "1: movl %%eax,%c4(%0)\n" \ + ".section .fixup,\"ax\"\n" \ + "2: movl $-"__stringify(ENOSYS)",%%eax\n" \ + " jmp 1b\n" \ + ".previous\n" \ + : \ + : "b" (_call), \ + "i" (offsetof(__typeof__(*_call), op)), \ + "i" (offsetof(__typeof__(*_call), args)), \ + "i" (sizeof(*(_call)->args)), \ + "i" (offsetof(__typeof__(*_call), result)) \ + /* all the caller-saves registers */ \ + : "rax", "rcx", "rdx", "rsi", "rdi", \ + "r8", "r9", "r10", "r11" ) \ #endif /* __ASM_X86_MULTICALL_H__ */ diff --git a/xen/include/asm-x86/system.h b/xen/include/asm-x86/system.h index 7111329..b80aca9 100644 --- a/xen/include/asm-x86/system.h +++ b/xen/include/asm-x86/system.h @@ -4,11 +4,12 @@ #include <xen/lib.h> #include <xen/bitops.h> #include <asm/processor.h> +#include <xen/stringify.h> -#define read_segment_register(name) \ -({ u16 __sel; \ - asm volatile ( "movw %%" STR(name) ",%0" : "=r" (__sel) ); \ - __sel; \ +#define read_segment_register(name) \ +({ u16 __sel; \ + asm volatile ( "movw %%" __stringify(name) ",%0" : "=r" (__sel) ); \ + __sel; \ }) #define wbinvd() \ diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h index 7bef8a6..03a11e3 100644 --- a/xen/include/xen/config.h +++ b/xen/include/xen/config.h @@ -82,9 +82,6 @@ #endif /* !__ASSEMBLY__ */ -#define __STR(...) #__VA_ARGS__ -#define STR(...) __STR(__VA_ARGS__) - #ifndef __ASSEMBLY__ /* Turn a plain number into a C unsigned long constant. */ #define __mk_unsigned_long(x) x ## UL -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v3 1/5] Use __stringify() as the only method for performing preprocessor stringificaion 2014-05-30 8:56 ` [PATCH v3 1/5] Use __stringify() as the only method for performing preprocessor stringificaion Feng Wu @ 2014-05-30 11:35 ` Jan Beulich 2014-06-03 0:42 ` Wu, Feng 0 siblings, 1 reply; 21+ messages in thread From: Jan Beulich @ 2014-05-30 11:35 UTC (permalink / raw) To: feng.wu, xen-devel Cc: ian.campbell, andrew.cooper3, tim, keir.xen, stefano.stabellini, boris.ostrovsky >>> Feng Wu <feng.wu@intel.com> 05/30/14 10:59 AM >>> >There are two ways of performing preprocessor stringificaion in the >current code: __stringify() from stringify.h, and STR() from config.h. >This patch consolidates down to one. Looking at the changes here I'm not really sure we want this as is. Is there anything going to break in the rest of the series if this patch was left out? Jan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 1/5] Use __stringify() as the only method for performing preprocessor stringificaion 2014-05-30 11:35 ` Jan Beulich @ 2014-06-03 0:42 ` Wu, Feng 2014-06-03 12:37 ` Wu, Feng 0 siblings, 1 reply; 21+ messages in thread From: Wu, Feng @ 2014-06-03 0:42 UTC (permalink / raw) To: Jan Beulich, xen-devel@lists.xen.org Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com > -----Original Message----- > From: Jan Beulich [mailto:jbeulich@suse.com] > Sent: Friday, May 30, 2014 7:36 PM > To: Wu, Feng; xen-devel@lists.xen.org > Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > stefano.stabellini@citrix.com; keir.xen@gmail.com; > boris.ostrovsky@oracle.com; tim@xen.org > Subject: Re: [PATCH v3 1/5] Use __stringify() as the only method for performing > preprocessor stringificaion > > >>> Feng Wu <feng.wu@intel.com> 05/30/14 10:59 AM >>> > >There are two ways of performing preprocessor stringificaion in the > >current code: __stringify() from stringify.h, and STR() from config.h. > >This patch consolidates down to one. > > Looking at the changes here I'm not really sure we want this as is. Is > there anything going to break in the rest of the series if this patch was > left out? > > Jan I think nothing will be broken without this patch. Andrew finds there are two different ways for handling this, and tend to unify them to one. This is the story. Thanks, Feng ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 1/5] Use __stringify() as the only method for performing preprocessor stringificaion 2014-06-03 0:42 ` Wu, Feng @ 2014-06-03 12:37 ` Wu, Feng 2014-06-03 13:05 ` Jan Beulich 0 siblings, 1 reply; 21+ messages in thread From: Wu, Feng @ 2014-06-03 12:37 UTC (permalink / raw) To: Wu, Feng, Jan Beulich, xen-devel@lists.xen.org Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com > -----Original Message----- > From: xen-devel-bounces@lists.xen.org > [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wu, Feng > Sent: Tuesday, June 03, 2014 8:43 AM > To: Jan Beulich; xen-devel@lists.xen.org > Cc: ian.campbell@citrix.com; andrew.cooper3@citrix.com; tim@xen.org; > keir.xen@gmail.com; stefano.stabellini@citrix.com; > boris.ostrovsky@oracle.com > Subject: Re: [Xen-devel] [PATCH v3 1/5] Use __stringify() as the only method for > performing preprocessor stringificaion > > > > > -----Original Message----- > > From: Jan Beulich [mailto:jbeulich@suse.com] > > Sent: Friday, May 30, 2014 7:36 PM > > To: Wu, Feng; xen-devel@lists.xen.org > > Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > > stefano.stabellini@citrix.com; keir.xen@gmail.com; > > boris.ostrovsky@oracle.com; tim@xen.org > > Subject: Re: [PATCH v3 1/5] Use __stringify() as the only method for > performing > > preprocessor stringificaion > > > > >>> Feng Wu <feng.wu@intel.com> 05/30/14 10:59 AM >>> > > >There are two ways of performing preprocessor stringificaion in the > > >current code: __stringify() from stringify.h, and STR() from config.h. > > >This patch consolidates down to one. > > > > Looking at the changes here I'm not really sure we want this as is. Is > > there anything going to break in the rest of the series if this patch was > > left out? > > > > Jan > > I think nothing will be broken without this patch. Andrew finds there are two > different > ways for handling this, and tend to unify them to one. This is the story. > > Thanks, > Feng Andrew & Jan, do you have any final decision about this change? Thanks, Feng > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 1/5] Use __stringify() as the only method for performing preprocessor stringificaion 2014-06-03 12:37 ` Wu, Feng @ 2014-06-03 13:05 ` Jan Beulich 2014-06-03 13:13 ` Wu, Feng 0 siblings, 1 reply; 21+ messages in thread From: Jan Beulich @ 2014-06-03 13:05 UTC (permalink / raw) To: Feng Wu Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com >>> On 03.06.14 at 14:37, <feng.wu@intel.com> wrote: > >> -----Original Message----- >> From: xen-devel-bounces@lists.xen.org >> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wu, Feng >> Sent: Tuesday, June 03, 2014 8:43 AM >> To: Jan Beulich; xen-devel@lists.xen.org >> Cc: ian.campbell@citrix.com; andrew.cooper3@citrix.com; tim@xen.org; >> keir.xen@gmail.com; stefano.stabellini@citrix.com; >> boris.ostrovsky@oracle.com >> Subject: Re: [Xen-devel] [PATCH v3 1/5] Use __stringify() as the only method > for >> performing preprocessor stringificaion >> >> >> >> > -----Original Message----- >> > From: Jan Beulich [mailto:jbeulich@suse.com] >> > Sent: Friday, May 30, 2014 7:36 PM >> > To: Wu, Feng; xen-devel@lists.xen.org >> > Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; >> > stefano.stabellini@citrix.com; keir.xen@gmail.com; >> > boris.ostrovsky@oracle.com; tim@xen.org >> > Subject: Re: [PATCH v3 1/5] Use __stringify() as the only method for >> performing >> > preprocessor stringificaion >> > >> > >>> Feng Wu <feng.wu@intel.com> 05/30/14 10:59 AM >>> >> > >There are two ways of performing preprocessor stringificaion in the >> > >current code: __stringify() from stringify.h, and STR() from config.h. >> > >This patch consolidates down to one. >> > >> > Looking at the changes here I'm not really sure we want this as is. Is >> > there anything going to break in the rest of the series if this patch was >> > left out? >> >> I think nothing will be broken without this patch. Andrew finds there are > two >> different >> ways for handling this, and tend to unify them to one. This is the story. > > Andrew & Jan, do you have any final decision about this change? As you've seen I applied the other patches in this series, but not this one. If such a cleanup was done, it should imo be done such that at the same time stringification gets dropped where pointlessly used, i.e. the set of use cases should get reduced to the bare minimum needed. And personally I have no problem gradually fading out STR() instead of doing this with a separate patch, thus reducing overall code churn. Jan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 1/5] Use __stringify() as the only method for performing preprocessor stringificaion 2014-06-03 13:05 ` Jan Beulich @ 2014-06-03 13:13 ` Wu, Feng 0 siblings, 0 replies; 21+ messages in thread From: Wu, Feng @ 2014-06-03 13:13 UTC (permalink / raw) To: Jan Beulich Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Tuesday, June 03, 2014 9:05 PM > To: Wu, Feng > Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > stefano.stabellini@citrix.com; keir.xen@gmail.com; xen-devel@lists.xen.org; > boris.ostrovsky@oracle.com; tim@xen.org > Subject: RE: [Xen-devel] [PATCH v3 1/5] Use __stringify() as the only method for > performing preprocessor stringificaion > > >>> On 03.06.14 at 14:37, <feng.wu@intel.com> wrote: > > > > >> -----Original Message----- > >> From: xen-devel-bounces@lists.xen.org > >> [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of Wu, Feng > >> Sent: Tuesday, June 03, 2014 8:43 AM > >> To: Jan Beulich; xen-devel@lists.xen.org > >> Cc: ian.campbell@citrix.com; andrew.cooper3@citrix.com; tim@xen.org; > >> keir.xen@gmail.com; stefano.stabellini@citrix.com; > >> boris.ostrovsky@oracle.com > >> Subject: Re: [Xen-devel] [PATCH v3 1/5] Use __stringify() as the only method > > for > >> performing preprocessor stringificaion > >> > >> > >> > >> > -----Original Message----- > >> > From: Jan Beulich [mailto:jbeulich@suse.com] > >> > Sent: Friday, May 30, 2014 7:36 PM > >> > To: Wu, Feng; xen-devel@lists.xen.org > >> > Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > >> > stefano.stabellini@citrix.com; keir.xen@gmail.com; > >> > boris.ostrovsky@oracle.com; tim@xen.org > >> > Subject: Re: [PATCH v3 1/5] Use __stringify() as the only method for > >> performing > >> > preprocessor stringificaion > >> > > >> > >>> Feng Wu <feng.wu@intel.com> 05/30/14 10:59 AM >>> > >> > >There are two ways of performing preprocessor stringificaion in the > >> > >current code: __stringify() from stringify.h, and STR() from config.h. > >> > >This patch consolidates down to one. > >> > > >> > Looking at the changes here I'm not really sure we want this as is. Is > >> > there anything going to break in the rest of the series if this patch was > >> > left out? > >> > >> I think nothing will be broken without this patch. Andrew finds there are > > two > >> different > >> ways for handling this, and tend to unify them to one. This is the story. > > > > Andrew & Jan, do you have any final decision about this change? > > As you've seen I applied the other patches in this series, but not this > one. If such a cleanup was done, it should imo be done such that at > the same time stringification gets dropped where pointlessly used, i.e. > the set of use cases should get reduced to the bare minimum needed. > And personally I have no problem gradually fading out STR() instead > of doing this with a separate patch, thus reducing overall code churn. > > Jan Okay, got it, thanks for the explanation! Thanks, Feng ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v3 2/5] x86: Add definitions for NOP operation 2014-05-30 8:56 [PATCH v3 0/5] x86: Use alternative mechanism to define CLAC/STAC Feng Wu 2014-05-30 8:56 ` [PATCH v3 1/5] Use __stringify() as the only method for performing preprocessor stringificaion Feng Wu @ 2014-05-30 8:56 ` Feng Wu 2014-05-30 8:56 ` [PATCH v3 3/5] x86: Make set_nmi_callback return the old nmi callback Feng Wu ` (2 subsequent siblings) 4 siblings, 0 replies; 21+ messages in thread From: Feng Wu @ 2014-05-30 8:56 UTC (permalink / raw) To: xen-devel Cc: Feng Wu, ian.campbell, andrew.cooper3, tim, keir.xen, stefano.stabellini, JBeulich, boris.ostrovsky This patch adds definitions for different length of NOP operation. Signed-off-by: Feng Wu <feng.wu@intel.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> --- xen/include/asm-x86/nops.h | 66 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 xen/include/asm-x86/nops.h diff --git a/xen/include/asm-x86/nops.h b/xen/include/asm-x86/nops.h new file mode 100644 index 0000000..05f9162 --- /dev/null +++ b/xen/include/asm-x86/nops.h @@ -0,0 +1,66 @@ +#ifndef __X86_ASM_NOPS_H__ +#define __X86_ASM_NOPS_H__ + +#include <xen/config.h> + +/* + * Define nops for use with alternative(). + */ + +/* + * Opteron 64bit nops + * 1: nop + * 2: osp nop + * 3: osp osp nop + * 4: osp osp osp nop + */ +#define K8_NOP1 0x90 +#define K8_NOP2 0x66,K8_NOP1 +#define K8_NOP3 0x66,K8_NOP2 +#define K8_NOP4 0x66,K8_NOP3 +#define K8_NOP5 K8_NOP3,K8_NOP2 +#define K8_NOP6 K8_NOP3,K8_NOP3 +#define K8_NOP7 K8_NOP4,K8_NOP3 +#define K8_NOP8 K8_NOP4,K8_NOP4 + +/* + * P6 nops + * uses eax dependencies (Intel-recommended choice) + * 1: nop + * 2: osp nop + * 3: nopl (%eax) + * 4: nopl 0x00(%eax) + * 5: nopl 0x00(%eax,%eax,1) + * 6: osp nopl 0x00(%eax,%eax,1) + * 7: nopl 0x00000000(%eax) + * 8: nopl 0x00000000(%eax,%eax,1) + * Note: All the above are assumed to be a single instruction. + * There is kernel code that depends on this. + */ +#define P6_NOP1 0x90 +#define P6_NOP2 0x66,0x90 +#define P6_NOP3 0x0f,0x1f,0x00 +#define P6_NOP4 0x0f,0x1f,0x40,0 +#define P6_NOP5 0x0f,0x1f,0x44,0x00,0 +#define P6_NOP6 0x66,0x0f,0x1f,0x44,0x00,0 +#define P6_NOP7 0x0f,0x1f,0x80,0,0,0,0 +#define P6_NOP8 0x0f,0x1f,0x84,0x00,0,0,0,0 + +#ifdef __ASSEMBLY__ +#define _ASM_MK_NOP(x) .byte x +#else +#define _ASM_MK_NOP(x) ".byte " __stringify(x) "\n" +#endif + +#define ASM_NOP1 _ASM_MK_NOP(K8_NOP1) +#define ASM_NOP2 _ASM_MK_NOP(K8_NOP2) +#define ASM_NOP3 _ASM_MK_NOP(K8_NOP3) +#define ASM_NOP4 _ASM_MK_NOP(K8_NOP4) +#define ASM_NOP5 _ASM_MK_NOP(K8_NOP5) +#define ASM_NOP6 _ASM_MK_NOP(K8_NOP6) +#define ASM_NOP7 _ASM_MK_NOP(K8_NOP7) +#define ASM_NOP8 _ASM_MK_NOP(K8_NOP8) + +#define ASM_NOP_MAX 8 + +#endif /* __X86_ASM_NOPS_H__ */ -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v3 3/5] x86: Make set_nmi_callback return the old nmi callback 2014-05-30 8:56 [PATCH v3 0/5] x86: Use alternative mechanism to define CLAC/STAC Feng Wu 2014-05-30 8:56 ` [PATCH v3 1/5] Use __stringify() as the only method for performing preprocessor stringificaion Feng Wu 2014-05-30 8:56 ` [PATCH v3 2/5] x86: Add definitions for NOP operation Feng Wu @ 2014-05-30 8:56 ` Feng Wu 2014-05-30 8:56 ` [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen Feng Wu 2014-05-30 8:56 ` [PATCH v3 5/5] x86: Use alternative mechanism to define CLAC/STAC Feng Wu 4 siblings, 0 replies; 21+ messages in thread From: Feng Wu @ 2014-05-30 8:56 UTC (permalink / raw) To: xen-devel Cc: Feng Wu, ian.campbell, andrew.cooper3, tim, keir.xen, stefano.stabellini, JBeulich, boris.ostrovsky This patch makes set_nmi_callback return the old nmi callback, so we can set it back later. Signed-off-by: Feng Wu <feng.wu@intel.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> --- xen/arch/x86/traps.c | 4 +++- xen/include/asm-x86/nmi.h | 4 ++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index 1722912..171cff0 100644 --- a/xen/arch/x86/traps.c +++ b/xen/arch/x86/traps.c @@ -3322,9 +3322,11 @@ void do_nmi(struct cpu_user_regs *regs) } } -void set_nmi_callback(nmi_callback_t callback) +nmi_callback_t set_nmi_callback(nmi_callback_t callback) { + nmi_callback_t old_nmi_callback = nmi_callback; nmi_callback = callback; + return old_nmi_callback; } void unset_nmi_callback(void) diff --git a/xen/include/asm-x86/nmi.h b/xen/include/asm-x86/nmi.h index 98b5e04..58cd9a1 100644 --- a/xen/include/asm-x86/nmi.h +++ b/xen/include/asm-x86/nmi.h @@ -15,9 +15,9 @@ typedef int (*nmi_callback_t)(struct cpu_user_regs *regs, int cpu); * set_nmi_callback * * Set a handler for an NMI. Only one handler may be - * set. Return 1 if the NMI was handled. + * set. Return the old nmi callback handler. */ -void set_nmi_callback(nmi_callback_t callback); +nmi_callback_t set_nmi_callback(nmi_callback_t callback); /** * unset_nmi_callback -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen 2014-05-30 8:56 [PATCH v3 0/5] x86: Use alternative mechanism to define CLAC/STAC Feng Wu ` (2 preceding siblings ...) 2014-05-30 8:56 ` [PATCH v3 3/5] x86: Make set_nmi_callback return the old nmi callback Feng Wu @ 2014-05-30 8:56 ` Feng Wu 2014-06-03 10:00 ` Jan Beulich 2014-05-30 8:56 ` [PATCH v3 5/5] x86: Use alternative mechanism to define CLAC/STAC Feng Wu 4 siblings, 1 reply; 21+ messages in thread From: Feng Wu @ 2014-05-30 8:56 UTC (permalink / raw) To: xen-devel Cc: Feng Wu, ian.campbell, andrew.cooper3, tim, keir.xen, stefano.stabellini, JBeulich, boris.ostrovsky This patch ports the basic alternative mechanism from Linux to Xen. With this mechanism, we can patch code based on the CPU features. Signed-off-by: Feng Wu <feng.wu@intel.com> --- xen/arch/x86/Makefile | 1 + xen/arch/x86/alternative.c | 213 ++++++++++++++++++++++++++++++++++++++ xen/arch/x86/setup.c | 3 + xen/arch/x86/xen.lds.S | 15 +++ xen/include/asm-x86/alternative.h | 78 ++++++++++++++ 5 files changed, 310 insertions(+) create mode 100644 xen/arch/x86/alternative.c create mode 100644 xen/include/asm-x86/alternative.h diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile index d502bdf..3734884 100644 --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -58,6 +58,7 @@ obj-y += crash.o obj-y += tboot.o obj-y += hpet.o obj-y += xstate.o +obj-y += alternative.o obj-$(crash_debug) += gdbstub.o diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c new file mode 100644 index 0000000..18cf17c --- /dev/null +++ b/xen/arch/x86/alternative.c @@ -0,0 +1,213 @@ +/****************************************************************************** + * alternative.c + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + */ + +#include <xen/types.h> +#include <asm/processor.h> +#include <asm/alternative.h> +#include <xen/init.h> +#include <asm/system.h> +#include <asm/traps.h> +#include <asm/nmi.h> + +#define MAX_PATCH_LEN (255-1) + +extern struct alt_instr __alt_instructions[], __alt_instructions_end[]; + +#ifdef K8_NOP1 +static const unsigned char k8nops[] __initconst = { + K8_NOP1, + K8_NOP2, + K8_NOP3, + K8_NOP4, + K8_NOP5, + K8_NOP6, + K8_NOP7, + K8_NOP8 +}; +static const unsigned char * const k8_nops[ASM_NOP_MAX+1] __initconst = { + NULL, + k8nops, + k8nops + 1, + k8nops + 1 + 2, + k8nops + 1 + 2 + 3, + k8nops + 1 + 2 + 3 + 4, + k8nops + 1 + 2 + 3 + 4 + 5, + k8nops + 1 + 2 + 3 + 4 + 5 + 6, + k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 +}; +#endif + +#ifdef P6_NOP1 +static const unsigned char p6nops[] __initconst = { + P6_NOP1, + P6_NOP2, + P6_NOP3, + P6_NOP4, + P6_NOP5, + P6_NOP6, + P6_NOP7, + P6_NOP8 +}; +static const unsigned char * const p6_nops[ASM_NOP_MAX+1] __initconst = { + NULL, + p6nops, + p6nops + 1, + p6nops + 1 + 2, + p6nops + 1 + 2 + 3, + p6nops + 1 + 2 + 3 + 4, + p6nops + 1 + 2 + 3 + 4 + 5, + p6nops + 1 + 2 + 3 + 4 + 5 + 6, + p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 +}; +#endif + +static const unsigned char * const *ideal_nops __initdata = k8_nops; + +static int __init mask_nmi_callback(struct cpu_user_regs *regs, int cpu) +{ + return 1; +} + +static void __init arch_init_ideal_nops(void) +{ + /* + * Due to a decoder implementation quirk, some + * specific Intel CPUs actually perform better with + * the "k8_nops" than with the SDM-recommended NOPs. + */ + if ( (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && + !(boot_cpu_data.x86 == 6 && + boot_cpu_data.x86_model >= 0x0f && + boot_cpu_data.x86_model != 0x1c && + boot_cpu_data.x86_model != 0x26 && + boot_cpu_data.x86_model != 0x27 && + boot_cpu_data.x86_model < 0x30) ) + ideal_nops = p6_nops; +} + +/* Use this to add nops to a buffer, then text_poke the whole buffer. */ +static void __init add_nops(void *insns, unsigned int len) +{ + while ( len > 0 ) + { + unsigned int noplen = len; + if ( noplen > ASM_NOP_MAX ) + noplen = ASM_NOP_MAX; + memcpy(insns, ideal_nops[noplen], noplen); + insns += noplen; + len -= noplen; + } +} + +/* + * text_poke_early - Update instructions on a live kernel at boot time + * @addr: address to modify + * @opcode: source of the copy + * @len: length to copy + * + * When you use this code to patch more than one byte of an instruction + * you need to make sure that other CPUs cannot execute this code in parallel. + * Also no thread must be currently preempted in the middle of these + * instructions. And on the local CPU you need to be protected again NMI or MCE + * handlers seeing an inconsistent instruction while you patch. + * + * This routine is called with local interrupt disabled. + */ +static void *__init text_poke_early(void *addr, const void *opcode, size_t len) +{ + memcpy(addr, opcode, len); + sync_core(); + + return addr; +} + +/* + * Replace instructions with better alternatives for this CPU type. + * This runs before SMP is initialized to avoid SMP problems with + * self modifying code. This implies that asymmetric systems where + * APs have less capabilities than the boot processor are not handled. + * Tough. Make sure you disable such features by hand. + */ +static void __init apply_alternatives(struct alt_instr *start, struct alt_instr *end) +{ + struct alt_instr *a; + u8 *instr, *replacement; + u8 insnbuf[MAX_PATCH_LEN]; + + ASSERT(!local_irq_is_enabled()); + + printk(KERN_INFO "alt table %p -> %p\n", start, end); + + /* + * The scan order should be from start to end. A later scanned + * alternative code can overwrite a previous scanned alternative code. + * Some kernel functions (e.g. memcpy, memset, etc) use this order to + * patch code. + * + * So be careful if you want to change the scan order to any other + * order. + */ + for ( a = start; a < end; a++ ) + { + instr = (u8 *)&a->instr_offset + a->instr_offset; + replacement = (u8 *)&a->repl_offset + a->repl_offset; + BUG_ON(a->replacementlen > a->instrlen); + BUG_ON(a->instrlen > sizeof(insnbuf)); + BUG_ON(a->cpuid >= NCAPINTS * 32); + if ( !boot_cpu_has(a->cpuid) ) + continue; + + memcpy(insnbuf, replacement, a->replacementlen); + + /* 0xe8/0xe9 is a relative jump; fix the offset. */ + if ( (*insnbuf & 0xfe) == 0xe8 && a->replacementlen == 5 ) + *(s32 *)(insnbuf + 1) += replacement - instr; + + add_nops(insnbuf + a->replacementlen, + a->instrlen - a->replacementlen); + text_poke_early(instr, insnbuf, a->instrlen); + } +} + +void __init alternative_instructions(void) +{ + nmi_callback_t saved_nmi_callback; + + arch_init_ideal_nops(); + + /* + * The patching is not fully atomic, so try to avoid local interruptions + * that might execute the to be patched code. + * Other CPUs are not running. + */ + saved_nmi_callback = set_nmi_callback(mask_nmi_callback); + + /* + * Don't stop machine check exceptions while patching. + * MCEs only happen when something got corrupted and in this + * case we must do something about the corruption. + * Ignoring it is worse than a unlikely patching race. + * Also machine checks tend to be broadcast and if one CPU + * goes into machine check the others follow quickly, so we don't + * expect a machine check to cause undue problems during to code + * patching. + */ + apply_alternatives(__alt_instructions, __alt_instructions_end); + + set_nmi_callback(saved_nmi_callback); +} diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 508649d..d16453a 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -48,6 +48,7 @@ #include <asm/setup.h> #include <xen/cpu.h> #include <asm/nmi.h> +#include <asm/alternative.h> /* opt_nosmp: If true, secondary processors are ignored. */ static bool_t __initdata opt_nosmp; @@ -1288,6 +1289,8 @@ void __init noreturn __start_xen(unsigned long mbi_p) if ( cpu_has_fsgsbase ) set_in_cr4(X86_CR4_FSGSBASE); + alternative_instructions(); + local_irq_enable(); pt_pci_init(); diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S index 17db361..d4b1f1a 100644 --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -105,6 +105,12 @@ SECTIONS .init.text : { _sinittext = .; *(.init.text) + /* + * Here are the replacement instructions. The linker sticks them + * as binary blobs. The .altinstructions has enough data to get + * the address and the length of them to patch the kernel safely. + */ + *(.altinstr_replacement) _einittext = .; } :text .init.data : { @@ -120,6 +126,15 @@ SECTIONS __trampoline_seg_start = .; *(.trampoline_seg) __trampoline_seg_stop = .; + /* + * struct alt_inst entries. From the header (alternative.h): + * "Alternative instructions for different CPU types or capabilities" + * Think locking instructions on spinlocks. + */ + . = ALIGN(8); + __alt_instructions = .; + *(.altinstructions) + __alt_instructions_end = .; . = ALIGN(8); __ctors_start = .; diff --git a/xen/include/asm-x86/alternative.h b/xen/include/asm-x86/alternative.h new file mode 100644 index 0000000..c746047 --- /dev/null +++ b/xen/include/asm-x86/alternative.h @@ -0,0 +1,78 @@ +#ifndef __X86_ALTERNATIVE_H__ +#define __X86_ALTERNATIVE_H__ + +#include <asm/nops.h> + +#ifdef __ASSEMBLY__ +.macro altinstruction_entry orig alt feature orig_len alt_len + .long \orig - . + .long \alt - . + .word \feature + .byte \orig_len + .byte \alt_len +.endm +#else +#include <xen/types.h> + +struct alt_instr { + s32 instr_offset; /* original instruction */ + s32 repl_offset; /* offset to replacement instruction */ + u16 cpuid; /* cpuid bit set for replacement */ + u8 instrlen; /* length of original instruction */ + u8 replacementlen; /* length of new instruction, <= instrlen */ +}; + +extern void alternative_instructions(void); + +#define OLDINSTR(oldinstr) "661:\n\t" oldinstr "\n662:\n" + +#define b_replacement(number) "663"#number +#define e_replacement(number) "664"#number + +#define alt_slen "662b-661b" +#define alt_rlen(number) e_replacement(number)"f-"b_replacement(number)"f" + +#define ALTINSTR_ENTRY(feature, number) \ + " .long 661b - .\n" /* label */ \ + " .long " b_replacement(number)"f - .\n" /* new instruction */ \ + " .word " __stringify(feature) "\n" /* feature bit */ \ + " .byte " alt_slen "\n" /* source len */ \ + " .byte " alt_rlen(number) "\n" /* replacement len */ + +#define DISCARD_ENTRY(number) /* rlen <= slen */ \ + " .byte 0xff + (" alt_rlen(number) ") - (" alt_slen ")\n" + +#define ALTINSTR_REPLACEMENT(newinstr, feature, number) /* replacement */ \ + b_replacement(number)":\n\t" newinstr "\n" e_replacement(number) ":\n\t" + +/* alternative assembly primitive: */ +#define ALTERNATIVE(oldinstr, newinstr, feature) \ + OLDINSTR(oldinstr) \ + ".pushsection .altinstructions,\"a\"\n" \ + ALTINSTR_ENTRY(feature, 1) \ + ".popsection\n" \ + ".pushsection .discard,\"aw\",@progbits\n" \ + DISCARD_ENTRY(1) \ + ".popsection\n" \ + ".pushsection .altinstr_replacement, \"ax\"\n" \ + ALTINSTR_REPLACEMENT(newinstr, feature, 1) \ + ".popsection" + +/* + * Alternative instructions for different CPU types or capabilities. + * + * This allows to use optimized instructions even on generic binary + * kernels. + * + * length of oldinstr must be longer or equal the length of newinstr + * It can be padded with nops as needed. + * + * For non barrier like inlines please define new variants + * without volatile and memory clobber. + */ +#define alternative(oldinstr, newinstr, feature) \ + asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) : : : "memory") + +#endif /* __ASSEMBLY__ */ + +#endif /* __X86_ALTERNATIVE_H__ */ -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen 2014-05-30 8:56 ` [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen Feng Wu @ 2014-06-03 10:00 ` Jan Beulich 2014-06-03 10:13 ` Wu, Feng 2014-06-03 13:05 ` Wu, Feng 0 siblings, 2 replies; 21+ messages in thread From: Jan Beulich @ 2014-06-03 10:00 UTC (permalink / raw) To: Feng Wu Cc: ian.campbell, andrew.cooper3, tim, xen-devel, keir.xen, stefano.stabellini, boris.ostrovsky >>> On 30.05.14 at 10:56, <feng.wu@intel.com> wrote: > +#ifdef K8_NOP1 > +static const unsigned char k8nops[] __initconst = { > + K8_NOP1, > + K8_NOP2, > + K8_NOP3, > + K8_NOP4, > + K8_NOP5, > + K8_NOP6, > + K8_NOP7, > + K8_NOP8 > +}; > +static const unsigned char * const k8_nops[ASM_NOP_MAX+1] __initconst = { > + NULL, > + k8nops, > + k8nops + 1, > + k8nops + 1 + 2, > + k8nops + 1 + 2 + 3, > + k8nops + 1 + 2 + 3 + 4, > + k8nops + 1 + 2 + 3 + 4 + 5, > + k8nops + 1 + 2 + 3 + 4 + 5 + 6, > + k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > +}; > +#endif > + > +#ifdef P6_NOP1 > +static const unsigned char p6nops[] __initconst = { > + P6_NOP1, > + P6_NOP2, > + P6_NOP3, > + P6_NOP4, > + P6_NOP5, > + P6_NOP6, > + P6_NOP7, > + P6_NOP8 > +}; > +static const unsigned char * const p6_nops[ASM_NOP_MAX+1] __initconst = { > + NULL, > + p6nops, > + p6nops + 1, > + p6nops + 1 + 2, > + p6nops + 1 + 2 + 3, > + p6nops + 1 + 2 + 3 + 4, > + p6nops + 1 + 2 + 3 + 4 + 5, > + p6nops + 1 + 2 + 3 + 4 + 5 + 6, > + p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > +}; > +#endif The uses of __initconst together with -fPIC cause build problems on older gcc. I fixed this up in a temporary way, but put a work item on my todo list to deal with this properly while at once converting alternative.o to alternative.init.o (as the file consists of only init code and data). Jan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen 2014-06-03 10:00 ` Jan Beulich @ 2014-06-03 10:13 ` Wu, Feng 2014-06-03 10:25 ` Jan Beulich 2014-06-03 13:05 ` Wu, Feng 1 sibling, 1 reply; 21+ messages in thread From: Wu, Feng @ 2014-06-03 10:13 UTC (permalink / raw) To: Jan Beulich Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Tuesday, June 03, 2014 6:00 PM > To: Wu, Feng > Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > stefano.stabellini@citrix.com; keir.xen@gmail.com; xen-devel@lists.xen.org; > boris.ostrovsky@oracle.com; tim@xen.org > Subject: Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from > Linux to Xen > > >>> On 30.05.14 at 10:56, <feng.wu@intel.com> wrote: > > +#ifdef K8_NOP1 > > +static const unsigned char k8nops[] __initconst = { > > + K8_NOP1, > > + K8_NOP2, > > + K8_NOP3, > > + K8_NOP4, > > + K8_NOP5, > > + K8_NOP6, > > + K8_NOP7, > > + K8_NOP8 > > +}; > > +static const unsigned char * const k8_nops[ASM_NOP_MAX+1] __initconst = > { > > + NULL, > > + k8nops, > > + k8nops + 1, > > + k8nops + 1 + 2, > > + k8nops + 1 + 2 + 3, > > + k8nops + 1 + 2 + 3 + 4, > > + k8nops + 1 + 2 + 3 + 4 + 5, > > + k8nops + 1 + 2 + 3 + 4 + 5 + 6, > > + k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > > +}; > > +#endif > > + > > +#ifdef P6_NOP1 > > +static const unsigned char p6nops[] __initconst = { > > + P6_NOP1, > > + P6_NOP2, > > + P6_NOP3, > > + P6_NOP4, > > + P6_NOP5, > > + P6_NOP6, > > + P6_NOP7, > > + P6_NOP8 > > +}; > > +static const unsigned char * const p6_nops[ASM_NOP_MAX+1] __initconst = > { > > + NULL, > > + p6nops, > > + p6nops + 1, > > + p6nops + 1 + 2, > > + p6nops + 1 + 2 + 3, > > + p6nops + 1 + 2 + 3 + 4, > > + p6nops + 1 + 2 + 3 + 4 + 5, > > + p6nops + 1 + 2 + 3 + 4 + 5 + 6, > > + p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > > +}; > > +#endif > > The uses of __initconst together with -fPIC cause build problems on > older gcc. I fixed this up in a temporary way, but put a work item on > my todo list to deal with this properly while at once converting > alternative.o to alternative.init.o (as the file consists of only init > code and data). > > Jan Thanks a lot for pointing this out. Do I need to do something for this? Thanks, Feng ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen 2014-06-03 10:13 ` Wu, Feng @ 2014-06-03 10:25 ` Jan Beulich 2014-06-03 10:35 ` Wu, Feng 0 siblings, 1 reply; 21+ messages in thread From: Jan Beulich @ 2014-06-03 10:25 UTC (permalink / raw) To: Feng Wu Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com >>> On 03.06.14 at 12:13, <feng.wu@intel.com> wrote: >> -----Original Message----- >> From: Jan Beulich [mailto:JBeulich@suse.com] >> Sent: Tuesday, June 03, 2014 6:00 PM >> To: Wu, Feng >> Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; >> stefano.stabellini@citrix.com; keir.xen@gmail.com; xen-devel@lists.xen.org; >> boris.ostrovsky@oracle.com; tim@xen.org >> Subject: Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from >> Linux to Xen >> >> >>> On 30.05.14 at 10:56, <feng.wu@intel.com> wrote: >> > +#ifdef K8_NOP1 >> > +static const unsigned char k8nops[] __initconst = { >> > + K8_NOP1, >> > + K8_NOP2, >> > + K8_NOP3, >> > + K8_NOP4, >> > + K8_NOP5, >> > + K8_NOP6, >> > + K8_NOP7, >> > + K8_NOP8 >> > +}; >> > +static const unsigned char * const k8_nops[ASM_NOP_MAX+1] __initconst = >> { >> > + NULL, >> > + k8nops, >> > + k8nops + 1, >> > + k8nops + 1 + 2, >> > + k8nops + 1 + 2 + 3, >> > + k8nops + 1 + 2 + 3 + 4, >> > + k8nops + 1 + 2 + 3 + 4 + 5, >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6, >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 >> > +}; >> > +#endif >> > + >> > +#ifdef P6_NOP1 >> > +static const unsigned char p6nops[] __initconst = { >> > + P6_NOP1, >> > + P6_NOP2, >> > + P6_NOP3, >> > + P6_NOP4, >> > + P6_NOP5, >> > + P6_NOP6, >> > + P6_NOP7, >> > + P6_NOP8 >> > +}; >> > +static const unsigned char * const p6_nops[ASM_NOP_MAX+1] __initconst = >> { >> > + NULL, >> > + p6nops, >> > + p6nops + 1, >> > + p6nops + 1 + 2, >> > + p6nops + 1 + 2 + 3, >> > + p6nops + 1 + 2 + 3 + 4, >> > + p6nops + 1 + 2 + 3 + 4 + 5, >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6, >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 >> > +}; >> > +#endif >> >> The uses of __initconst together with -fPIC cause build problems on >> older gcc. I fixed this up in a temporary way, but put a work item on >> my todo list to deal with this properly while at once converting >> alternative.o to alternative.init.o (as the file consists of only init >> code and data). > > Thanks a lot for pointing this out. Do I need to do something for this? If you're up to it, you could of course save me the time to do what I outlined above... Jan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen 2014-06-03 10:25 ` Jan Beulich @ 2014-06-03 10:35 ` Wu, Feng 2014-06-03 10:51 ` Jan Beulich 0 siblings, 1 reply; 21+ messages in thread From: Wu, Feng @ 2014-06-03 10:35 UTC (permalink / raw) To: Jan Beulich Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Tuesday, June 03, 2014 6:25 PM > To: Wu, Feng > Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > stefano.stabellini@citrix.com; keir.xen@gmail.com; xen-devel@lists.xen.org; > boris.ostrovsky@oracle.com; tim@xen.org > Subject: RE: [PATCH v3 4/5] x86: Port the basic alternative mechanism from > Linux to Xen > > >>> On 03.06.14 at 12:13, <feng.wu@intel.com> wrote: > >> -----Original Message----- > >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> Sent: Tuesday, June 03, 2014 6:00 PM > >> To: Wu, Feng > >> Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > >> stefano.stabellini@citrix.com; keir.xen@gmail.com; > xen-devel@lists.xen.org; > >> boris.ostrovsky@oracle.com; tim@xen.org > >> Subject: Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from > >> Linux to Xen > >> > >> >>> On 30.05.14 at 10:56, <feng.wu@intel.com> wrote: > >> > +#ifdef K8_NOP1 > >> > +static const unsigned char k8nops[] __initconst = { > >> > + K8_NOP1, > >> > + K8_NOP2, > >> > + K8_NOP3, > >> > + K8_NOP4, > >> > + K8_NOP5, > >> > + K8_NOP6, > >> > + K8_NOP7, > >> > + K8_NOP8 > >> > +}; > >> > +static const unsigned char * const k8_nops[ASM_NOP_MAX+1] > __initconst = > >> { > >> > + NULL, > >> > + k8nops, > >> > + k8nops + 1, > >> > + k8nops + 1 + 2, > >> > + k8nops + 1 + 2 + 3, > >> > + k8nops + 1 + 2 + 3 + 4, > >> > + k8nops + 1 + 2 + 3 + 4 + 5, > >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6, > >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > >> > +}; > >> > +#endif > >> > + > >> > +#ifdef P6_NOP1 > >> > +static const unsigned char p6nops[] __initconst = { > >> > + P6_NOP1, > >> > + P6_NOP2, > >> > + P6_NOP3, > >> > + P6_NOP4, > >> > + P6_NOP5, > >> > + P6_NOP6, > >> > + P6_NOP7, > >> > + P6_NOP8 > >> > +}; > >> > +static const unsigned char * const p6_nops[ASM_NOP_MAX+1] > __initconst = > >> { > >> > + NULL, > >> > + p6nops, > >> > + p6nops + 1, > >> > + p6nops + 1 + 2, > >> > + p6nops + 1 + 2 + 3, > >> > + p6nops + 1 + 2 + 3 + 4, > >> > + p6nops + 1 + 2 + 3 + 4 + 5, > >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6, > >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > >> > +}; > >> > +#endif > >> > >> The uses of __initconst together with -fPIC cause build problems on > >> older gcc. I fixed this up in a temporary way, but put a work item on > >> my todo list to deal with this properly while at once converting > >> alternative.o to alternative.init.o (as the file consists of only init > >> code and data). > > > > Thanks a lot for pointing this out. Do I need to do something for this? > > If you're up to it, you could of course save me the time to do what I > outlined above... > > Jan >From the above you mentioned, seems we cannot use __initconst together with -fPIC on some old gcc. Do you know what is the reason, and does the problem occur with "__initdata ", "__init ", etc? Thanks, Feng ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen 2014-06-03 10:35 ` Wu, Feng @ 2014-06-03 10:51 ` Jan Beulich 2014-06-03 11:42 ` Wu, Feng 0 siblings, 1 reply; 21+ messages in thread From: Jan Beulich @ 2014-06-03 10:51 UTC (permalink / raw) To: Feng Wu Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com >>> On 03.06.14 at 12:35, <feng.wu@intel.com> wrote: > >> -----Original Message----- >> From: Jan Beulich [mailto:JBeulich@suse.com] >> Sent: Tuesday, June 03, 2014 6:25 PM >> To: Wu, Feng >> Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; >> stefano.stabellini@citrix.com; keir.xen@gmail.com; xen-devel@lists.xen.org; >> boris.ostrovsky@oracle.com; tim@xen.org >> Subject: RE: [PATCH v3 4/5] x86: Port the basic alternative mechanism from >> Linux to Xen >> >> >>> On 03.06.14 at 12:13, <feng.wu@intel.com> wrote: >> >> -----Original Message----- >> >> From: Jan Beulich [mailto:JBeulich@suse.com] >> >> Sent: Tuesday, June 03, 2014 6:00 PM >> >> To: Wu, Feng >> >> Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; >> >> stefano.stabellini@citrix.com; keir.xen@gmail.com; >> xen-devel@lists.xen.org; >> >> boris.ostrovsky@oracle.com; tim@xen.org >> >> Subject: Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from >> >> Linux to Xen >> >> >> >> >>> On 30.05.14 at 10:56, <feng.wu@intel.com> wrote: >> >> > +#ifdef K8_NOP1 >> >> > +static const unsigned char k8nops[] __initconst = { >> >> > + K8_NOP1, >> >> > + K8_NOP2, >> >> > + K8_NOP3, >> >> > + K8_NOP4, >> >> > + K8_NOP5, >> >> > + K8_NOP6, >> >> > + K8_NOP7, >> >> > + K8_NOP8 >> >> > +}; >> >> > +static const unsigned char * const k8_nops[ASM_NOP_MAX+1] >> __initconst = >> >> { >> >> > + NULL, >> >> > + k8nops, >> >> > + k8nops + 1, >> >> > + k8nops + 1 + 2, >> >> > + k8nops + 1 + 2 + 3, >> >> > + k8nops + 1 + 2 + 3 + 4, >> >> > + k8nops + 1 + 2 + 3 + 4 + 5, >> >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6, >> >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 >> >> > +}; >> >> > +#endif >> >> > + >> >> > +#ifdef P6_NOP1 >> >> > +static const unsigned char p6nops[] __initconst = { >> >> > + P6_NOP1, >> >> > + P6_NOP2, >> >> > + P6_NOP3, >> >> > + P6_NOP4, >> >> > + P6_NOP5, >> >> > + P6_NOP6, >> >> > + P6_NOP7, >> >> > + P6_NOP8 >> >> > +}; >> >> > +static const unsigned char * const p6_nops[ASM_NOP_MAX+1] >> __initconst = >> >> { >> >> > + NULL, >> >> > + p6nops, >> >> > + p6nops + 1, >> >> > + p6nops + 1 + 2, >> >> > + p6nops + 1 + 2 + 3, >> >> > + p6nops + 1 + 2 + 3 + 4, >> >> > + p6nops + 1 + 2 + 3 + 4 + 5, >> >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6, >> >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 >> >> > +}; >> >> > +#endif >> >> >> >> The uses of __initconst together with -fPIC cause build problems on >> >> older gcc. I fixed this up in a temporary way, but put a work item on >> >> my todo list to deal with this properly while at once converting >> >> alternative.o to alternative.init.o (as the file consists of only init >> >> code and data). >> > >> > Thanks a lot for pointing this out. Do I need to do something for this? >> >> If you're up to it, you could of course save me the time to do what I >> outlined above... > > From the above you mentioned, seems we cannot use __initconst together with > -fPIC on > some old gcc. Do you know what is the reason, and does the problem occur > with "__initdata ", "__init ", etc? The problem is only with __initconst afaict, the reason being that with -fPIC constant data with relocations doesn't get put into r/o sections (irrespective of the "const" modifier) by older gcc versions. Jan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen 2014-06-03 10:51 ` Jan Beulich @ 2014-06-03 11:42 ` Wu, Feng 2014-06-03 11:59 ` Jan Beulich 0 siblings, 1 reply; 21+ messages in thread From: Wu, Feng @ 2014-06-03 11:42 UTC (permalink / raw) To: Jan Beulich Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Tuesday, June 03, 2014 6:51 PM > To: Wu, Feng > Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > stefano.stabellini@citrix.com; keir.xen@gmail.com; xen-devel@lists.xen.org; > boris.ostrovsky@oracle.com; tim@xen.org > Subject: RE: [PATCH v3 4/5] x86: Port the basic alternative mechanism from > Linux to Xen > > >>> On 03.06.14 at 12:35, <feng.wu@intel.com> wrote: > > > > >> -----Original Message----- > >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> Sent: Tuesday, June 03, 2014 6:25 PM > >> To: Wu, Feng > >> Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > >> stefano.stabellini@citrix.com; keir.xen@gmail.com; > xen-devel@lists.xen.org; > >> boris.ostrovsky@oracle.com; tim@xen.org > >> Subject: RE: [PATCH v3 4/5] x86: Port the basic alternative mechanism from > >> Linux to Xen > >> > >> >>> On 03.06.14 at 12:13, <feng.wu@intel.com> wrote: > >> >> -----Original Message----- > >> >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> >> Sent: Tuesday, June 03, 2014 6:00 PM > >> >> To: Wu, Feng > >> >> Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > >> >> stefano.stabellini@citrix.com; keir.xen@gmail.com; > >> xen-devel@lists.xen.org; > >> >> boris.ostrovsky@oracle.com; tim@xen.org > >> >> Subject: Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism > from > >> >> Linux to Xen > >> >> > >> >> >>> On 30.05.14 at 10:56, <feng.wu@intel.com> wrote: > >> >> > +#ifdef K8_NOP1 > >> >> > +static const unsigned char k8nops[] __initconst = { > >> >> > + K8_NOP1, > >> >> > + K8_NOP2, > >> >> > + K8_NOP3, > >> >> > + K8_NOP4, > >> >> > + K8_NOP5, > >> >> > + K8_NOP6, > >> >> > + K8_NOP7, > >> >> > + K8_NOP8 > >> >> > +}; > >> >> > +static const unsigned char * const k8_nops[ASM_NOP_MAX+1] > >> __initconst = > >> >> { > >> >> > + NULL, > >> >> > + k8nops, > >> >> > + k8nops + 1, > >> >> > + k8nops + 1 + 2, > >> >> > + k8nops + 1 + 2 + 3, > >> >> > + k8nops + 1 + 2 + 3 + 4, > >> >> > + k8nops + 1 + 2 + 3 + 4 + 5, > >> >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6, > >> >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > >> >> > +}; > >> >> > +#endif > >> >> > + > >> >> > +#ifdef P6_NOP1 > >> >> > +static const unsigned char p6nops[] __initconst = { > >> >> > + P6_NOP1, > >> >> > + P6_NOP2, > >> >> > + P6_NOP3, > >> >> > + P6_NOP4, > >> >> > + P6_NOP5, > >> >> > + P6_NOP6, > >> >> > + P6_NOP7, > >> >> > + P6_NOP8 > >> >> > +}; > >> >> > +static const unsigned char * const p6_nops[ASM_NOP_MAX+1] > >> __initconst = > >> >> { > >> >> > + NULL, > >> >> > + p6nops, > >> >> > + p6nops + 1, > >> >> > + p6nops + 1 + 2, > >> >> > + p6nops + 1 + 2 + 3, > >> >> > + p6nops + 1 + 2 + 3 + 4, > >> >> > + p6nops + 1 + 2 + 3 + 4 + 5, > >> >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6, > >> >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > >> >> > +}; > >> >> > +#endif > >> >> > >> >> The uses of __initconst together with -fPIC cause build problems on > >> >> older gcc. I fixed this up in a temporary way, but put a work item on > >> >> my todo list to deal with this properly while at once converting > >> >> alternative.o to alternative.init.o (as the file consists of only init > >> >> code and data). > >> > > >> > Thanks a lot for pointing this out. Do I need to do something for this? > >> > >> If you're up to it, you could of course save me the time to do what I > >> outlined above... > > > > From the above you mentioned, seems we cannot use __initconst together > with > > -fPIC on > > some old gcc. Do you know what is the reason, and does the problem occur > > with "__initdata ", "__init ", etc? > > The problem is only with __initconst afaict, the reason being that with > -fPIC constant data with relocations doesn't get put into r/o sections > (irrespective of the "const" modifier) by older gcc versions. > > Jan I am a little curious, from xen.lds.S, we can see both *(.init.data) and *(.init.rodata) go into section .init.data. So even we use __initconst and "const" modifier, the data is still not constant, right? Thanks, Feng ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen 2014-06-03 11:42 ` Wu, Feng @ 2014-06-03 11:59 ` Jan Beulich 0 siblings, 0 replies; 21+ messages in thread From: Jan Beulich @ 2014-06-03 11:59 UTC (permalink / raw) To: Feng Wu Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com >>> On 03.06.14 at 13:42, <feng.wu@intel.com> wrote: > I am a little curious, from xen.lds.S, we can see both *(.init.data) and > *(.init.rodata) go into section .init.data. > So even we use __initconst and "const" modifier, the data is still not > constant, right? The use of the "const" modifier makes it so the compiler guarantees const-ness. But yes, this isn't being enforced at the processor level. The same compiler issue as observed here prevents the use of __initdata for "const" objects: Some older gcc versions produce "section type conflict" warnings/errors if you try to put both const and non-const data into the same section. Jan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen 2014-06-03 10:00 ` Jan Beulich 2014-06-03 10:13 ` Wu, Feng @ 2014-06-03 13:05 ` Wu, Feng 2014-06-03 13:10 ` Jan Beulich 1 sibling, 1 reply; 21+ messages in thread From: Wu, Feng @ 2014-06-03 13:05 UTC (permalink / raw) To: Jan Beulich Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Tuesday, June 03, 2014 6:00 PM > To: Wu, Feng > Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > stefano.stabellini@citrix.com; keir.xen@gmail.com; xen-devel@lists.xen.org; > boris.ostrovsky@oracle.com; tim@xen.org > Subject: Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from > Linux to Xen > > >>> On 30.05.14 at 10:56, <feng.wu@intel.com> wrote: > > +#ifdef K8_NOP1 > > +static const unsigned char k8nops[] __initconst = { > > + K8_NOP1, > > + K8_NOP2, > > + K8_NOP3, > > + K8_NOP4, > > + K8_NOP5, > > + K8_NOP6, > > + K8_NOP7, > > + K8_NOP8 > > +}; > > +static const unsigned char * const k8_nops[ASM_NOP_MAX+1] __initconst = > { > > + NULL, > > + k8nops, > > + k8nops + 1, > > + k8nops + 1 + 2, > > + k8nops + 1 + 2 + 3, > > + k8nops + 1 + 2 + 3 + 4, > > + k8nops + 1 + 2 + 3 + 4 + 5, > > + k8nops + 1 + 2 + 3 + 4 + 5 + 6, > > + k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > > +}; > > +#endif > > + > > +#ifdef P6_NOP1 > > +static const unsigned char p6nops[] __initconst = { > > + P6_NOP1, > > + P6_NOP2, > > + P6_NOP3, > > + P6_NOP4, > > + P6_NOP5, > > + P6_NOP6, > > + P6_NOP7, > > + P6_NOP8 > > +}; > > +static const unsigned char * const p6_nops[ASM_NOP_MAX+1] __initconst = > { > > + NULL, > > + p6nops, > > + p6nops + 1, > > + p6nops + 1 + 2, > > + p6nops + 1 + 2 + 3, > > + p6nops + 1 + 2 + 3 + 4, > > + p6nops + 1 + 2 + 3 + 4 + 5, > > + p6nops + 1 + 2 + 3 + 4 + 5 + 6, > > + p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > > +}; > > +#endif > > The uses of __initconst together with -fPIC cause build problems on > older gcc. I fixed this up in a temporary way, but put a work item on > my todo list to deal with this properly while at once converting > alternative.o to alternative.init.o (as the file consists of only init > code and data). > > Jan BTW, is there any difference after converting alternative.o to alternative.init.o, since everything in alternative.c has already been __init__? Thanks, Feng ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen 2014-06-03 13:05 ` Wu, Feng @ 2014-06-03 13:10 ` Jan Beulich 2014-06-03 13:27 ` Wu, Feng 0 siblings, 1 reply; 21+ messages in thread From: Jan Beulich @ 2014-06-03 13:10 UTC (permalink / raw) To: Feng Wu Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com >>> On 03.06.14 at 15:05, <feng.wu@intel.com> wrote: > >> -----Original Message----- >> From: Jan Beulich [mailto:JBeulich@suse.com] >> Sent: Tuesday, June 03, 2014 6:00 PM >> To: Wu, Feng >> Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; >> stefano.stabellini@citrix.com; keir.xen@gmail.com; xen-devel@lists.xen.org; >> boris.ostrovsky@oracle.com; tim@xen.org >> Subject: Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from >> Linux to Xen >> >> >>> On 30.05.14 at 10:56, <feng.wu@intel.com> wrote: >> > +#ifdef K8_NOP1 >> > +static const unsigned char k8nops[] __initconst = { >> > + K8_NOP1, >> > + K8_NOP2, >> > + K8_NOP3, >> > + K8_NOP4, >> > + K8_NOP5, >> > + K8_NOP6, >> > + K8_NOP7, >> > + K8_NOP8 >> > +}; >> > +static const unsigned char * const k8_nops[ASM_NOP_MAX+1] __initconst = >> { >> > + NULL, >> > + k8nops, >> > + k8nops + 1, >> > + k8nops + 1 + 2, >> > + k8nops + 1 + 2 + 3, >> > + k8nops + 1 + 2 + 3 + 4, >> > + k8nops + 1 + 2 + 3 + 4 + 5, >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6, >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 >> > +}; >> > +#endif >> > + >> > +#ifdef P6_NOP1 >> > +static const unsigned char p6nops[] __initconst = { >> > + P6_NOP1, >> > + P6_NOP2, >> > + P6_NOP3, >> > + P6_NOP4, >> > + P6_NOP5, >> > + P6_NOP6, >> > + P6_NOP7, >> > + P6_NOP8 >> > +}; >> > +static const unsigned char * const p6_nops[ASM_NOP_MAX+1] __initconst = >> { >> > + NULL, >> > + p6nops, >> > + p6nops + 1, >> > + p6nops + 1 + 2, >> > + p6nops + 1 + 2 + 3, >> > + p6nops + 1 + 2 + 3 + 4, >> > + p6nops + 1 + 2 + 3 + 4 + 5, >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6, >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 >> > +}; >> > +#endif >> >> The uses of __initconst together with -fPIC cause build problems on >> older gcc. I fixed this up in a temporary way, but put a work item on >> my todo list to deal with this properly while at once converting >> alternative.o to alternative.init.o (as the file consists of only init >> code and data). > > BTW, is there any difference after converting alternative.o to > alternative.init.o, since > everything in alternative.c has already been __init__? Yes, there is: String literals will also get moved to .init.*. Plus inadvertent addition of non-init code/date would get detected at build time. Jan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen 2014-06-03 13:10 ` Jan Beulich @ 2014-06-03 13:27 ` Wu, Feng 0 siblings, 0 replies; 21+ messages in thread From: Wu, Feng @ 2014-06-03 13:27 UTC (permalink / raw) To: Jan Beulich Cc: ian.campbell@citrix.com, andrew.cooper3@citrix.com, tim@xen.org, xen-devel@lists.xen.org, keir.xen@gmail.com, stefano.stabellini@citrix.com, boris.ostrovsky@oracle.com > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Tuesday, June 03, 2014 9:10 PM > To: Wu, Feng > Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > stefano.stabellini@citrix.com; keir.xen@gmail.com; xen-devel@lists.xen.org; > boris.ostrovsky@oracle.com; tim@xen.org > Subject: RE: [PATCH v3 4/5] x86: Port the basic alternative mechanism from > Linux to Xen > > >>> On 03.06.14 at 15:05, <feng.wu@intel.com> wrote: > > > > >> -----Original Message----- > >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> Sent: Tuesday, June 03, 2014 6:00 PM > >> To: Wu, Feng > >> Cc: andrew.cooper3@citrix.com; ian.campbell@citrix.com; > >> stefano.stabellini@citrix.com; keir.xen@gmail.com; > xen-devel@lists.xen.org; > >> boris.ostrovsky@oracle.com; tim@xen.org > >> Subject: Re: [PATCH v3 4/5] x86: Port the basic alternative mechanism from > >> Linux to Xen > >> > >> >>> On 30.05.14 at 10:56, <feng.wu@intel.com> wrote: > >> > +#ifdef K8_NOP1 > >> > +static const unsigned char k8nops[] __initconst = { > >> > + K8_NOP1, > >> > + K8_NOP2, > >> > + K8_NOP3, > >> > + K8_NOP4, > >> > + K8_NOP5, > >> > + K8_NOP6, > >> > + K8_NOP7, > >> > + K8_NOP8 > >> > +}; > >> > +static const unsigned char * const k8_nops[ASM_NOP_MAX+1] > __initconst = > >> { > >> > + NULL, > >> > + k8nops, > >> > + k8nops + 1, > >> > + k8nops + 1 + 2, > >> > + k8nops + 1 + 2 + 3, > >> > + k8nops + 1 + 2 + 3 + 4, > >> > + k8nops + 1 + 2 + 3 + 4 + 5, > >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6, > >> > + k8nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > >> > +}; > >> > +#endif > >> > + > >> > +#ifdef P6_NOP1 > >> > +static const unsigned char p6nops[] __initconst = { > >> > + P6_NOP1, > >> > + P6_NOP2, > >> > + P6_NOP3, > >> > + P6_NOP4, > >> > + P6_NOP5, > >> > + P6_NOP6, > >> > + P6_NOP7, > >> > + P6_NOP8 > >> > +}; > >> > +static const unsigned char * const p6_nops[ASM_NOP_MAX+1] > __initconst = > >> { > >> > + NULL, > >> > + p6nops, > >> > + p6nops + 1, > >> > + p6nops + 1 + 2, > >> > + p6nops + 1 + 2 + 3, > >> > + p6nops + 1 + 2 + 3 + 4, > >> > + p6nops + 1 + 2 + 3 + 4 + 5, > >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6, > >> > + p6nops + 1 + 2 + 3 + 4 + 5 + 6 + 7 > >> > +}; > >> > +#endif > >> > >> The uses of __initconst together with -fPIC cause build problems on > >> older gcc. I fixed this up in a temporary way, but put a work item on > >> my todo list to deal with this properly while at once converting > >> alternative.o to alternative.init.o (as the file consists of only init > >> code and data). > > > > BTW, is there any difference after converting alternative.o to > > alternative.init.o, since > > everything in alternative.c has already been __init__? > > Yes, there is: String literals will also get moved to .init.*. Plus > inadvertent addition of non-init code/date would get detected at > build time. > > Jan Thanks, good to know this! Feng ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v3 5/5] x86: Use alternative mechanism to define CLAC/STAC 2014-05-30 8:56 [PATCH v3 0/5] x86: Use alternative mechanism to define CLAC/STAC Feng Wu ` (3 preceding siblings ...) 2014-05-30 8:56 ` [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen Feng Wu @ 2014-05-30 8:56 ` Feng Wu 4 siblings, 0 replies; 21+ messages in thread From: Feng Wu @ 2014-05-30 8:56 UTC (permalink / raw) To: xen-devel Cc: Feng Wu, ian.campbell, andrew.cooper3, tim, keir.xen, stefano.stabellini, JBeulich, boris.ostrovsky This patch use alternative mechanism to define CLAC/STAC. Signed-off-by: Feng Wu <feng.wu@intel.com> Reviewed-by: Andrew Cooper <andrew.cooper@citrix.com> --- xen/include/asm-x86/asm_defns.h | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/xen/include/asm-x86/asm_defns.h b/xen/include/asm-x86/asm_defns.h index 87a462f..f8ef1f8 100644 --- a/xen/include/asm-x86/asm_defns.h +++ b/xen/include/asm-x86/asm_defns.h @@ -10,6 +10,7 @@ #include <asm/percpu.h> #include <xen/stringify.h> #include <asm/cpufeature.h> +#include <asm/alternative.h> #ifndef __ASSEMBLY__ void ret_from_intr(void); @@ -166,26 +167,28 @@ void ret_from_intr(void); #define __ASM_STAC .byte 0x0f,0x01,0xcb #ifdef __ASSEMBLY__ -#define ASM_AC(op) \ - btl $X86_FEATURE_SMAP & 31, \ - CPUINFO_FEATURE_OFFSET(X86_FEATURE_SMAP)+boot_cpu_data(%rip); \ - jnc 881f; \ - __ASM_##op; \ -881: +#define ASM_AC(op) \ + 661: ASM_NOP3; \ + .pushsection .altinstr_replacement, "ax"; \ + 662: __ASM_##op; \ + .popsection; \ + .pushsection .altinstructions, "a"; \ + altinstruction_entry 661b, 662b, X86_FEATURE_SMAP, 3, 3; \ + .popsection #define ASM_STAC ASM_AC(STAC) #define ASM_CLAC ASM_AC(CLAC) #else static inline void clac(void) { - if ( boot_cpu_has(X86_FEATURE_SMAP) ) - asm volatile (__stringify(__ASM_CLAC) : : : "memory"); + /* Note: a barrier is implicit in alternative() */ + alternative(ASM_NOP3, __stringify(__ASM_CLAC), X86_FEATURE_SMAP); } static inline void stac(void) { - if ( boot_cpu_has(X86_FEATURE_SMAP) ) - asm volatile (__stringify(__ASM_STAC) : : : "memory"); + /* Note: a barrier is implicit in alternative() */ + alternative(ASM_NOP3, __stringify(__ASM_STAC), X86_FEATURE_SMAP); } #endif -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 21+ messages in thread
end of thread, other threads:[~2014-06-03 13:27 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-05-30 8:56 [PATCH v3 0/5] x86: Use alternative mechanism to define CLAC/STAC Feng Wu 2014-05-30 8:56 ` [PATCH v3 1/5] Use __stringify() as the only method for performing preprocessor stringificaion Feng Wu 2014-05-30 11:35 ` Jan Beulich 2014-06-03 0:42 ` Wu, Feng 2014-06-03 12:37 ` Wu, Feng 2014-06-03 13:05 ` Jan Beulich 2014-06-03 13:13 ` Wu, Feng 2014-05-30 8:56 ` [PATCH v3 2/5] x86: Add definitions for NOP operation Feng Wu 2014-05-30 8:56 ` [PATCH v3 3/5] x86: Make set_nmi_callback return the old nmi callback Feng Wu 2014-05-30 8:56 ` [PATCH v3 4/5] x86: Port the basic alternative mechanism from Linux to Xen Feng Wu 2014-06-03 10:00 ` Jan Beulich 2014-06-03 10:13 ` Wu, Feng 2014-06-03 10:25 ` Jan Beulich 2014-06-03 10:35 ` Wu, Feng 2014-06-03 10:51 ` Jan Beulich 2014-06-03 11:42 ` Wu, Feng 2014-06-03 11:59 ` Jan Beulich 2014-06-03 13:05 ` Wu, Feng 2014-06-03 13:10 ` Jan Beulich 2014-06-03 13:27 ` Wu, Feng 2014-05-30 8:56 ` [PATCH v3 5/5] x86: Use alternative mechanism to define CLAC/STAC Feng Wu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).