>>> Andrew Cooper <andrew.coop...@citrix.com> 02/28/18 7:20 PM >>> >On 28/02/18 16:22, Jan Beulich wrote: >>>>> On 26.02.18 at 12:35, <andrew.coop...@citrix.com> wrote: >>> --- a/xen/include/asm-x86/alternative-asm.h >>> +++ b/xen/include/asm-x86/alternative-asm.h >>> @@ -1,6 +1,8 @@ >>> #ifndef _ASM_X86_ALTERNATIVE_ASM_H_ >>> #define _ASM_X86_ALTERNATIVE_ASM_H_ >>> >>> +#include <asm/nops.h> >>> + >>> #ifdef __ASSEMBLY__ >>> >>> /* >>> @@ -18,6 +20,14 @@ >>> .byte \pad_len >>> .endm >>> >>> +.macro mknops nr_bytes >>> +#ifdef HAVE_AS_NOP_DIRECTIVE >>> + .nop \nr_bytes, ASM_NOP_MAX >> And do you really need to specify ASM_NOP_MAX here? What's >> wrong with letting the assembler pick what it wants as the longest >> NOP? > >I don't want a toolchain change to cause us to go beyond 11 byte nops, >because of the associated decode stall on almost all hardware. Using >ASM_NOP_MAX seemed like the easiest way to keep the end result >consistent, irrespective of toolchain support.
I don't understand - an earlier patch takes care of runtime replacing them anyway. What stalls can then result? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel