lkml.org 
[lkml]   [2020]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [tip: x86/cpu] x86/cpu: Use INVPCID mnemonic in invpcid.h
On Tue, May 12, 2020 at 5:15 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, May 12, 2020 at 04:26:37PM +0200, Uros Bizjak wrote:
> > Actually, the order was correct for AT&T syntax in the original patch.
> >
> > The insn template for AT&T syntax goes:
> >
> > insn arg2, arg1, arg0
> >
> > where rightmost arguments are output operands.
> >
> > The operands in asm template go
> >
> > asm ("insn template" : output0, output1 : input0, input1 : clobbers)
> >
> > so, in effect:
> >
> > asm ("insn template" : arg0, arg1 : arg2, arg3: clobbers)
> >
> > As you can see, the operand order in insn tempate is reversed for AT&T
> > syntax. I didn't notice the reversal of operands in your improvement.
>
> Your version had:
>
> + asm volatile ("invpcid %1, %0"
> + : : "r" (type), "m" (desc) : "memory");
>
> with "type" being the 0th operand and "desc" being the 1st operand in
> the input operands list.

Correct.

> The order of the operands after the "invpcid" mnemonic are the other way
> around though: you first have %1 which is "desc" and then %0 which is
> the type.

Also correct. Because AT&T has right-to-left operand order, while asm
statement has left-to-right operand order.

> I simply swapped the arguments order in the input operands list, after
> the second ':'
>
> + asm volatile("invpcid %[desc], %[type]"
> + :: [desc] "m" (desc), [type] "r" (type) : "memory");
>
> so that "desc" comes first and "type" second when reading from
> left-to-right in both

But this is not correct, AT&T insn template should have right-to-left order.

> 1. *after* the "invpcid" mnemonic and
> 2. in the input operands list, after the second ':'.

This is not the case throughout the kernel source. Please see for
example sync_bitops, where:

asm volatile("lock; " __ASM_SIZE(bts) " %1,%0"
: "+m" (ADDR)
: "Ir" (nr)
: "memory");

(to support my claim, I tried to find instruction with two input
operands; there are some in KVM, but these were also written by
myself).

> And since I'm using the symbolic operand names, then the order just
> works because looking at a before-and-after thing doesn't show any
> opcode differences:

Symbolic operands are agnostic to the position in the asm clause, so
it really doesn't matter much. It just doesn't feel right, when other
cases follow different order.

> $ diff -suprN /tmp/before /tmp/after
> Files /tmp/before and /tmp/after are identical

Sure, otherwise assembler would complain.

> Makes sense?

Well, I don't want to bikeshed around this anymore, so any way is good.

Uros.

\
 
 \ /
  Last update: 2020-05-12 17:55    [W:0.127 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site