All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-tip-commits@vger.kernel.org,
	"H. Peter Anvin (Intel)" <hpa@zytor.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	x86 <x86@kernel.org>
Subject: Re: [tip: x86/cpu] x86/cpu: Use INVPCID mnemonic in invpcid.h
Date: Tue, 12 May 2020 17:15:22 +0200	[thread overview]
Message-ID: <20200512151522.GB6859@zn.tnic> (raw)
In-Reply-To: <CAFULd4bZLkME4kn9bmbOBMtd+ZpNnsH-w8a6tPdtmpV57WSHtw@mail.gmail.com>

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.

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.

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

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

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:

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

$ cat /tmp/before
ffffffff81058392:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff8105c542:	66 44 0f 38 82 04 24 	invpcid (%rsp),%r8
ffffffff8105c5b4:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff8105ccd2:	66 44 0f 38 82 14 24 	invpcid (%rsp),%r10
ffffffff8105d6cf:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff8105d7ef:	66 0f 38 82 1c 24    	invpcid (%rsp),%rbx
ffffffff8105e4db:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff8106067b:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff8169547d:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff82406698 <x86_noinvpcid_setup>:
ffffffff824066a3:	75 27                	jne    ffffffff824066cc <x86_noinvpcid_setup+0x34>
ffffffff824066b4:	73 16                	jae    ffffffff824066cc <x86_noinvpcid_setup+0x34>
ffffffff824124db:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff82412e34:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff82415158:	66 0f 38 82 44 24 10 	invpcid 0x10(%rsp),%rax

$ cat /tmp/after
ffffffff81058392:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff8105c542:	66 44 0f 38 82 04 24 	invpcid (%rsp),%r8
ffffffff8105c5b4:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff8105ccd2:	66 44 0f 38 82 14 24 	invpcid (%rsp),%r10
ffffffff8105d6cf:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff8105d7ef:	66 0f 38 82 1c 24    	invpcid (%rsp),%rbx
ffffffff8105e4db:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff8106067b:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff8169547d:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff82406698 <x86_noinvpcid_setup>:
ffffffff824066a3:	75 27                	jne    ffffffff824066cc <x86_noinvpcid_setup+0x34>
ffffffff824066b4:	73 16                	jae    ffffffff824066cc <x86_noinvpcid_setup+0x34>
ffffffff824124db:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff82412e34:	66 0f 38 82 04 24    	invpcid (%rsp),%rax
ffffffff82415158:	66 0f 38 82 44 24 10 	invpcid 0x10(%rsp),%rax

Makes sense?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

  reply	other threads:[~2020-05-12 15:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08  9:22 [PATCH] x86: Use INVPCID mnemonic in invpcid.h Uros Bizjak
2020-05-08 11:34 ` Peter Zijlstra
2020-05-08 17:32 ` H. Peter Anvin
2020-05-09 11:33 ` Borislav Petkov
2020-05-12 14:10 ` [tip: x86/cpu] x86/cpu: " tip-bot2 for Uros Bizjak
2020-05-12 14:26   ` Uros Bizjak
2020-05-12 15:15     ` Borislav Petkov [this message]
2020-05-12 15:54       ` Uros Bizjak
2020-05-12 16:28         ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200512151522.GB6859@zn.tnic \
    --to=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=ubizjak@gmail.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.