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

Borislav Petkov
2025-12-02T10:48:10Z

On Tue, Dec 02, 2025 at 08:26:00AM +0200, Adrian Hunter wrote:
> The instruction decoder is permissive in the sense that it cannot
> tell if an instruction is valid, only what its properties are assuming
> it is valid. There is no need to validate EVEX-only.
>
> ev->evo makes sense to allow for another instruction.

I have no clue what you mean here.

> # (ev): this opcode requires EVEX prefix.
> # (evo): this opcode is changed by EVEX prefix (EVEX opcode)

I can certainly see the "evo" part. This opcode - 0f 79 - means different
things with different prefixes. So "ev" is wrong here because this opcode does
*not* require EVEX - it can exist without EVEX.

So the "ev" -> "evo" change is probably the right thing to do ATM.

> It puts the instruction into a different opcode/addressing-mode space
> (different attribute table) so we probably need to keep using it like that.

Probably?

This scheme of putting an insn in a different attribute table because of
randomly selected insn properties looks silly and error prone to me. If you
want to mark it as part of the whole AVX512* set, then use the fact that it
has an EVEX prefix. That's all.

And if you want to differentiate on VEX.pp, then invent a new "superscript" or
whatever this thing is called which is called VEX_pp or whatever. But do not
call it 66 to mean the legacy prefix because that is wrong and it conflates
two incompatible things as it can be seen here, and causes trouble.

I mean, there should be a direct 1:1 match between insn encoding and flags we
need and that'll give us the different attribute tables as this thing is
designed and all is fine and dandy.

I'd say.

--
Regards/Gruss,
Boris.