Re: [Xen-devel] [PATCH] x86/build: Use new .nops directive when available

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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?

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel