[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/build: Use new .nops directive when available
>>> On 16.08.18 at 13:57, <roger.pau@xxxxxxxxxx> wrote: > On Thu, Aug 16, 2018 at 04:18:03AM -0600, Jan Beulich wrote: >> >>> On 16.08.18 at 11:55, <roger.pau@xxxxxxxxxx> wrote: >> > On Wed, Aug 15, 2018 at 06:57:38PM +0100, Andrew Cooper wrote: >> >> --- a/xen/arch/x86/Rules.mk >> >> +++ b/xen/arch/x86/Rules.mk >> >> @@ -29,6 +29,10 @@ $(call as-option-add,CFLAGS,CC,"invpcid > (%rax)$$(comma)%rax",-DHAVE_AS_INVPCID) >> >> $(call as-option-add,CFLAGS,CC,\ >> >> ".if ((1 > 0) < 0); .error \"\";.endif",,-DHAVE_AS_NEGATIVE_TRUE) >> >> >> >> +# Check to see whether the assmbler supports the .nop directive. >> >> +$(call as-option-add,CFLAGS,CC,\ >> >> + ".L1: .L2: .nops (.L2 - .L1)$$(comma)9",-DHAVE_AS_NOP_DIRECTIVE) >> > >> > I think I remember commenting on an earlier version of this about the >> > usage of the CONTROL parameter. I would expect the assembler to >> > use the most optimized version by default, is that not the case? >> >> How could it, without knowing what the target hardware is? And even >> if it could, what is considered "most optimized" tends to change every >> once in a while (or else we wouldn't have different NOP flavors to >> begin with). > > I think I haven't explained myself well. By using the CONTROL > parameter we limit the max length of a nop instruction to 9 bytes > instead of using the maximum supported by the assembler (11 bytes IIRC > for 64bit). Is this done because there are issues with using nops > 9 > bytes? There the problems start that I've hinted at towards Andrew: gas supports up to 11-byte NOPs despite the SDM saying otherwise at present. But ORM and SDM disagree as well, for the 3- and 6-byte variants. Otoh AMD recommends up to 11-byte NOPs for Fam15 and earlier, and suggests even using up to 15-byte ones on Fam17. Besides that I also wonder whether in 64-bit mode REX prefixes wouldn't be preferable over operand size override ones. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |