From: Alexandre Chartre <alexandre.chartre@oracle.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: alexandre.chartre@oracle.com, jpoimboe@kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] objtool/x86: Fix NOP decode
Date: Thu, 25 Sep 2025 11:55:23 +0200 [thread overview]
Message-ID: <f17d5e92-2aaa-43e7-ba67-ea5e7d07601a@oracle.com> (raw)
In-Reply-To: <20250924184158.GZ3245006@noisy.programming.kicks-ass.net>
On 9/24/25 20:41, Peter Zijlstra wrote:
> On Wed, Sep 24, 2025 at 07:34:00PM +0200, Alexandre Chartre wrote:
>>
>> On 9/24/25 15:45, Peter Zijlstra wrote:
>>> For x86_64 the kernel consistently uses 2 instructions for all NOPs:
>>>
>>> 90 - NOP
>>> 0f 1f /0 - NOPL
>>>
>>>
>>> Notably:
>>>
>>> - REP NOP is PAUSE, not a NOP instruction.
>>>
>>> - 0f {0c...0f} is reserved space,
>>> except for 0f 0d /1, which is PREFETCHW, not a NOP.
>>>
>>> - 0f {19,1c...1f} is reserved space,
>>> except for 0f 1f /0, which is NOPL.
>>>
>>> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>>> ---
>>> tools/objtool/arch/x86/decode.c | 12 +++++++-----
>>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>>
>>> --- a/tools/objtool/arch/x86/decode.c
>>> +++ b/tools/objtool/arch/x86/decode.c
>>> @@ -494,7 +494,8 @@ int arch_decode_instruction(struct objto
>>> break;
>>> case 0x90:
>>> + if (prefix != 0xf3) /* REP NOP := PAUSE */
>>> + insn->type = INSN_NOP;
>>> break;
>>
>> So this covers NOP1 (0x90) and NOP2 (0x66 0x90), right?
>
> Yes. Everything with opcode 0x90, except 0xf3 0x90, which as stated is
> PAUSE.
>
What about 0x49 0x90, which is xchg (XCHG r8,rAX) ?
>>> case 0x9c:
>>> @@ -547,13 +548,14 @@ int arch_decode_instruction(struct objto
>>> } else if (op2 == 0x0b || op2 == 0xb9) {
>>> + /* ud2, ud1 */
>>> insn->type = INSN_BUG;
>>> + } else if (op2 == 0x1f) {
>>> + /* 0f 1f /0 := NOPL */
>>> + if (modrm_reg == 0)
>>> + insn->type = INSN_NOP;
>>> } else if (op2 == 0x1e) {
>>
>> And this covers all other NOPs (0x0f 0x1f ...), including NOP6 which has
>> a 0x66 preifx (0x66 0xf 0x1f ...) ?
>
> Sorta, it accepts everything with opcode 0f 1f and modrm_reg==0, which is
> how NOPL is encoded.
>
> Both: 66 66 66 66 66 66 66 66 66 66 66 66 66 66 90 (NOP15)
> And: 66 66 66 66 66 66 66 0f 1f 84 00 00 00 00 00 (NOP15)
>
> will be accepted here as max length instructions. The kernel will not
> actually use those, since a bunch of micro archs have decode penalties
> for too many prefixes.
>
>> From arch/x86/include/asm/nops.h we have:
>
> You're looking at old code :-)
>
Correct, I was on the 5.15 branch.
alex.
>> /*
>> * Generic 64bit nops from GAS:
>> *
>> * 1: nop
>> * 2: osp nop
>> * 3: nopl (%eax)
>> * 4: nopl 0x00(%eax)
>> * 5: nopl 0x00(%eax,%eax,1)
>> * 6: osp nopl 0x00(%eax,%eax,1)
>> * 7: nopl 0x00000000(%eax)
>> * 8: nopl 0x00000000(%eax,%eax,1)
>
> * 9: cs nopl 0x00000000(%eax,%eax,1)
> * 10: osp cs nopl 0x00000000(%eax,%eax,1)
> * 11: osp osp cs nopl 0x00000000(%eax,%eax,1)
>
>> */
>> #define BYTES_NOP1 0x90
>> #define BYTES_NOP2 0x66,BYTES_NOP1
>> #define BYTES_NOP3 0x0f,0x1f,0x00
>> #define BYTES_NOP4 0x0f,0x1f,0x40,0x00
>> #define BYTES_NOP5 0x0f,0x1f,0x44,0x00,0x00
>> #define BYTES_NOP6 0x66,BYTES_NOP5
>> #define BYTES_NOP7 0x0f,0x1f,0x80,0x00,0x00,0x00,0x00
>> #define BYTES_NOP8 0x0f,0x1f,0x84,0x00,0x00,0x00,0x00,0x00
>
> #define BYTES_NOP9 0x2e,BYTES_NOP8
> #define BYTES_NOP10 0x66,BYTES_NOP9
> #define BYTES_NOP11 0x66,BYTES_NOP10
>
> But yes, first two are NOP and then it switches to NOPL for 3 bytes and
> longer (2 opcode, 1 modrm). Where for 11 bytes we have:
>
> - 3 prefixes
> - 2 opcode
> - 1 modrm
> - 1 sib
> - 4 displacement
>
next prev parent reply other threads:[~2025-09-25 9:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 13:45 [PATCH 0/3] objtool: Few x86 decoder updates Peter Zijlstra
2025-09-24 13:45 ` [PATCH 1/3] objtool/x86: Remove 0xea hack Peter Zijlstra
2025-09-25 9:55 ` Alexandre Chartre
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2025-09-24 13:45 ` [PATCH 2/3] objtool/x86: Add UDB support Peter Zijlstra
2025-09-25 9:56 ` Alexandre Chartre
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2025-09-24 13:45 ` [PATCH 3/3] objtool/x86: Fix NOP decode Peter Zijlstra
2025-09-24 17:34 ` Alexandre Chartre
2025-09-24 18:41 ` Peter Zijlstra
2025-09-25 9:55 ` Alexandre Chartre [this message]
2025-09-25 10:03 ` Peter Zijlstra
2025-09-25 10:42 ` Peter Zijlstra
2025-09-25 11:29 ` Andrew Cooper
2025-09-25 12:43 ` Peter Zijlstra
2025-09-25 13:04 ` Alexandre Chartre
2025-09-25 14:11 ` Peter Zijlstra
2025-09-25 13:05 ` Alexandre Chartre
2025-10-14 11:47 ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
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=f17d5e92-2aaa-43e7-ba67-ea5e7d07601a@oracle.com \
--to=alexandre.chartre@oracle.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--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.