Xen project Mailing List

Re: [Xen-devel] [PATCH v2] x86: fix alternative_callN usage of ALTERNATIVE asm macro

From: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Date: Mon, 27 May 2019 14:39:41 +0200

Authentication-results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=roger.pau@xxxxxxxxxx; spf=Pass smtp.mailfrom=roger.pau@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxxxxxxxxxxxxx

Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>

Delivery-date: Mon, 27 May 2019 12:40:02 +0000

Ironport-sdr: wS8Lcz6LGUI/HTFYw5pirvfCeY1Fxm6m9CSl/9jnysHJGJMW6xorEDIwdy2d6LVo0MnlHLtDsk AhEWGsXNh/WI2mxvaskw+fwCEuBOoN72nFueG/TXsiobABWkT4SS+cBSgI2yYXv0TTH6ls4Q5i DNtYuTw1P4AzYm9BE7XRNKt9vmmYho/Yk/S8/bK6g69bSix6ODuyfAHw54KilHUA3wxpB92hB7 Arwv5vW53g0FdPtxKDsNnZsTm/HDoFj/A/8EfCpkQfFpMtNUAa6rCVgu/dKk1T88SnC1ghA90Z 9P0=

List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, May 23, 2019 at 03:41:23AM -0600, Jan Beulich wrote: > >>> On 22.05.19 at 18:45, <roger.pau@xxxxxxxxxx> wrote: > > alternative_callN using inline assembly to generate the alternative > > patch sites should be using the ALTERNATIVE C preprocessor macro > > rather than the ALTERNATIVE assembly macro, > > Why? See INDIRECT_{CALL,JMP}. My goal, as said on irc, would be > to eventually eliminate the redundant C macros, in favor of just using > the assembler ones. Using the current assembly macros for inline asm alternatives would regress the build on llvm based toolchains. If that's indeed the path forward I will have to look into making those work in inline assembly instances. > > the more that using the > > assembly macro in an inline assembly instance causes the following > > error on llvm based toolchains: > > > > <instantiation>:1:1: error: invalid symbol redefinition > > .L0_orig_s: call *genapic+64(%rip); .L0_orig_e: .L0_diff = (.L0_repl_e1 - > > .L0_repl_s1) - (... > > The understanding I get is that clang doesn't properly support the > \@ construct, expanding it to zero every time. Yes, that's my understanding also. I've already filled a bug report: https://bugs.llvm.org/show_bug.cgi?id=42034 > That's a clang bug > imo, and hence the wording here should reflect this, rather than > suggesting the code is broken.(I seem to vaguely recall an issue > with clang instantiating a new assembly environment every time > it encounters an asm().) IIRC I've fixed that one upstream quite some time ago, and should be fixed in versions >= 6. > Without clang fixed, and with us wanting > to be able to continue to build with clang, this then voids the entire > purpose of f850619692 ("x86/alternatives: allow using assembler > macros in favor of C ones"), which irc was originally part of the > series, but went in much ahead of it. I can look into workarounds to this, the one that comes to mind is using .altmacro and LOCAL in order to create unique labels in the macro. I can test if such approach would work if the plan is to only rely on the assembly alternative code. > > > --- a/xen/include/asm-x86/alternative.h > > +++ b/xen/include/asm-x86/alternative.h > > @@ -202,9 +202,8 @@ extern void alternative_branches(void); > > rettype ret_; \ > > register unsigned long r10_ asm("r10"); \ > > register unsigned long r11_ asm("r11"); \ > > - asm volatile (__stringify(ALTERNATIVE "call *%c[addr](%%rip)", \ > > - "call .", \ > > - X86_FEATURE_ALWAYS) \ > > + asm volatile (ALTERNATIVE("call *%c[addr](%%rip)", "call .", \ > > + X86_FEATURE_ALWAYS) \ > > : ALT_CALL ## n ## _OUT, "=a" (ret_), \ > > "=r" (r10_), "=r" (r11_) ASM_CALL_CONSTRAINT \ > > : [addr] "i" (&(func)), "g" (func) \ > > Okay, luckily the code change itself is simple enough, so it really > wasn't that I had to use the variant used to make things work at > all. Since the only change requested is related to the commit message, would you be OK to update the commit message to: ---8<--- x86: remove alternative_callN usage of ALTERNATIVE asm macro alternative_callN using inline assembly to generate the alternative patch sites should be using the ALTERNATIVE C preprocessor macro rather than the ALTERNATIVE assembly macro, the more that using the assembly macro in an inline assembly instance triggers the following bug on llvm based toolchains: <instantiation>:1:1: error: invalid symbol redefinition .L0_orig_s: call *genapic+64(%rip); .L0_orig_e: .L0_diff = (.L0_repl_e1 - .L0_repl_s1) - (... ^ <instantiation>:1:37: error: invalid symbol redefinition .L0_orig_s: call *genapic+64(%rip); .L0_orig_e: .L0_diff = (.L0_repl_e1 - .L0_repl_s1) - (... ^ <instantiation>:1:60: error: invalid reassignment of non-absolute variable '.L0_diff' .L0_orig_s: call *genapic+64(%rip); .L0_orig_e: .L0_diff = (.L0_repl_e1 - .L0_repl_s1) - (... ^ <inline asm>:1:2: note: while in macro instantiation ALTERNATIVE "call *genapic+64(%rip)", "call .", X86_FEATURE_LM ^ <instantiation>:1:156: error: invalid symbol redefinition ...- (.L0_orig_e - .L0_orig_s); mknops ((-(.L0_diff > 0)) * .L0_diff); .L0_orig_p: ^ <instantiation>:18:5: error: invalid symbol redefinition .L0_repl_s1: call .; .L0_repl_e1: ^ <instantiation>:18:26: error: invalid symbol redefinition .L0_repl_s1: call .; .L0_repl_e1: ^ <instantiation>:1:1: error: invalid symbol redefinition .L0_orig_s: call *genapic+64(%rip); .L0_orig_e: .L0_diff = (.L0_repl_e1 - .L0_repl_s1) - (... ^ <instantiation>:1:37: error: invalid symbol redefinition .L0_orig_s: call *genapic+64(%rip); .L0_orig_e: .L0_diff = (.L0_repl_e1 - .L0_repl_s1) - (... ^ <instantiation>:1:60: error: invalid reassignment of non-absolute variable '.L0_diff' .L0_orig_s: call *genapic+64(%rip); .L0_orig_e: .L0_diff = (.L0_repl_e1 - .L0_repl_s1) - (... ^ <inline asm>:1:2: note: while in macro instantiation ALTERNATIVE "call *genapic+64(%rip)", "call .", X86_FEATURE_LM ^ <instantiation>:1:156: error: invalid symbol redefinition ...- (.L0_orig_e - .L0_orig_s); mknops ((-(.L0_diff > 0)) * .L0_diff); .L0_orig_p: ^ <instantiation>:18:5: error: invalid symbol redefinition .L0_repl_s1: call .; .L0_repl_e1: ^ <instantiation>:18:26: error: invalid symbol redefinition .L0_repl_s1: call .; .L0_repl_e1: ^ <instantiation>:1:1: error: invalid symbol redefinition .L0_orig_s: call *genapic+64(%rip); .L0_orig_e: .L0_diff = (.L0_repl_e1 - .L0_repl_s1) - (... ^ <instantiation>:1:37: error: invalid symbol redefinition .L0_orig_s: call *genapic+64(%rip); .L0_orig_e: .L0_diff = (.L0_repl_e1 - .L0_repl_s1) - (... ^ <instantiation>:1:60: error: invalid reassignment of non-absolute variable '.L0_diff' .L0_orig_s: call *genapic+64(%rip); .L0_orig_e: .L0_diff = (.L0_repl_e1 - .L0_repl_s1) - (... ^ <inline asm>:1:2: note: while in macro instantiation ALTERNATIVE "call *genapic+64(%rip)", "call .", X86_FEATURE_LM ^ <instantiation>:1:156: error: invalid symbol redefinition ...- (.L0_orig_e - .L0_orig_s); mknops ((-(.L0_diff > 0)) * .L0_diff); .L0_orig_p: ^ <instantiation>:18:5: error: invalid symbol redefinition .L0_repl_s1: call .; .L0_repl_e1: ^ <instantiation>:18:26: error: invalid symbol redefinition .L0_repl_s1: call .; .L0_repl_e1: ^ This is a bug in llvm that needs to be fixed before switching to use the alternative assembly macros in inline assembly call sites. Fixes: 67d01cdb5 ("x86: infrastructure to allow converting certain indirect calls to direct ones") Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.