linux-kernel - Re: [PATCH V2 2/4] x86/insn: Add AVX-512 support to the instruction decoder

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251201190138.GDaS3mEm9P5UGfd8jY@fat_crate.local>
Date: Mon, 1 Dec 2025 20:01:38 +0100
From: Borislav Petkov <bp@...en8.de>
To: Adrian Hunter <adrian.hunter@...el.com>
Cc: Masami Hiramatsu <mhiramat@...nel.org>, linux-kernel@...r.kernel.org,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andy Lutomirski <luto@...capital.net>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH V2 2/4] x86/insn: Add AVX-512 support to the instruction
 decoder

On Mon, Dec 01, 2025 at 08:15:19PM +0200, Adrian Hunter wrote:
> EXTRQ Vo,Uo (66) has a mandatory 66 prefix like vcvtps2uqq/pd2uqq Vx,Wx (66),(ev) so they end up on the same attribute table, but (ev) results in INAT_EVEXONLY which is unwanted.
> 
> Changing that from (ev) to (evo) is probably all that is needed e.g.
> 
> +79: VMWRITE Gy,Ey | EXTRQ Vo,Uo (66) | vcvtps2udq/pd2udq Vx,Wpd (evo) | vcvtsd2usi Gv,Wx (F2),(ev) | vcvtss2usi Gv,Wx (F3),(ev) | vcvtps2uqq/pd2uqq Vx,Wx (66),(evo)
> 

That still sounds to me like a hack: looking at the SDM, that thing:

VCVTPS2UQQ—Convert Packed Single Precision Floating-Point Values to Packed
Unsigned Quadword Integer Values

*is* EVEX-only insn:

EVEX.128.66.0F.W0

the "66" meaning in this case EVEX.pp which are the VEX.pp two bits with value
1b meaning there's an implied 66 legacy prefix.

To make it more concrete, let's take an example from the binutils testsuite:

62 f1 7d 4f 79 f5[    ]*vcvtps2uqq zmm6\{k7\},ymm5

and that's basically:

Extended VEctor prefiX:         0x62
  P1: [R:1|X:1|B:1|R':1|rsv:0|mm:1] 0xf1
  P2: [W:0|vvvv:0xf    |rsv:1|pp:1] 0x7d
  P3: [z:0|L':1|L:0|b:0|V':1|aaa:7] 0x4f

with the opcode 0x79 and EVEX.pp=1b, as expected.

So there's no real 66 prefix there.

But our opcode map says:

"# Last Prefix Superscripts
#  - (66): the last prefix is 0x66"

So we're using the marking (66) to mean both an explicit 66 legacy prefix and
an implied *VEX.pp=1 66 prefix equivalence.

So now the question is, why do the *VEX opcodes need that (66) marking at all?
For operand sizing?

Looking at our example insn VCVTPS2UQQ, I don't see any other encoding where
66 is not present. And there's nothing in the pseudo code either. So VEX.pp=1
is part of the encoding of that insn.

So, that (66) there is not really the prefix ...

Hmm?

-- 
Regards/Gruss,
    Boris.

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