[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.