On 12/02/16 08:13, Jan Beulich wrote: >>>> On 11.02.16 at 20:41, <andrew.coop...@citrix.com> wrote: >> On 11/02/16 19:25, Andrew Cooper wrote: >>> --- a/xen/arch/x86/flushtlb.c >>> +++ b/xen/arch/x86/flushtlb.c >>> @@ -141,10 +141,10 @@ void flush_area_local(const void *va, unsigned int >>> flags) >>> { >>> alternative(ASM_NOP3, "sfence", X86_FEATURE_CLFLUSHOPT); >>> for ( i = 0; i < sz; i += c->x86_clflush_size ) >>> - alternative_input("rex clflush %0", >>> - "data16 clflush %0", >>> - X86_FEATURE_CLFLUSHOPT, >>> - "m" (((const char *)va)[i])); >>> + alternative_input(".byte 0x3e; clflush %0", /* %ds >>> override. */ >>> + "data16 clflush %0", /* clflushopt. >>> >> */ >>> + X86_FEATURE_CLFLUSHOPT, >>> + "m" (((const char *)va)[i])); >>> } >>> else >>> { >> It turns out that Clang is far more useful at diagnosing this issue than >> GCC. >> >> flushtlb.c:144:18: error: invalid instruction mnemonic 'rex' >> alternative_input("rex clflush %0", >> ^ > Except that 'rex' is by no means invalid. If anything Clang's internal > assembler doesn't support it (and hence is not gas compatible).
That is tangential to the point. The useful part is the end message: > <inline asm>:2:2: note: instantiated into assembly here > rex clflush (%r15,%rdx) > ^~~~~~~~~~~~~~~~~~~~~~~ which makes it substantially more clear that there is both a REX prefix and REX.B required. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel