Messages in this thread |  | | Date | Tue, 2 Dec 2025 11:47:46 +0100 | | From | Borislav Petkov <> | | Subject | Re: [PATCH V2 2/4] x86/insn: Add AVX-512 support to the instruction decoder |
| |
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.
https://people.kernel.org/tglx/notes-about-netiquette
|  |