Re: [PATCH 02/18] target/i386: validate VEX.W for AVX instructions

[Richard Henderson <richard.henderson@linaro.org>]

On 10/14/23 03:01, Paolo Bonzini wrote:
> Instructions in VEX exception class 6 generally look at the value of
> VEX.W.  Note that the manual places some instructions incorrectly in
> class 4, for example VPERMQ which has no non-VEX encoding and no legacy
> SSE analogue.  AMD does a mess of its own, as documented in the comment
> that this patch adds.
> 
> Most of them are checked for VEX.W=0, and are listed in the manual
> (though with an omission) in table 2-16; VPERMQ and VPERMPD check for
> VEX.W=1, which is only listed in the instruction description.  Others,
> such as VPSRLV, VPSLLV and the FMA3 instructions, use VEX.W to switch
> between a 32-bit and 64-bit operation.
> 
> Fix more of the class 4/class 6 mismatches, and implement the check for
> VEX.W in TCG.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>   target/i386/tcg/decode-new.c.inc | 133 +++++++++++++++++++++----------
>   target/i386/tcg/decode-new.h     |   6 ++
>   2 files changed, 99 insertions(+), 40 deletions(-)
> 
> diff --git a/target/i386/tcg/decode-new.c.inc b/target/i386/tcg/decode-new.c.inc
> index 790339eaf25..850271e0898 100644
> --- a/target/i386/tcg/decode-new.c.inc
> +++ b/target/i386/tcg/decode-new.c.inc
> @@ -43,6 +43,47 @@
>    * There are a couple cases in which instructions (e.g. MOVD) write the
>    * whole XMM or MM register but are established incorrectly in the manual
>    * as "d" or "q".  These have to be fixed for the decoder to work correctly.
> + *
> + * Speaking about imprecisions in the manual, the decoder treats all
> + * exception-class 4 instructions as having an optional VEX prefix, and
> + * all exception-class 6 instructions as having a mandatory VEX prefix.
> + * This is true except for a dozen instructions; these are in exception
> + * class 4 but do not ignore the VEX.W bit (which does not even exist
> + * without a VEX prefix).  These instructions are mostly listed in Intel's
> + * table 2-16, but with a few exceptions.
> + *
> + * The AMD manual has more precise subclasses for exceptions, and unlike Intel
> + * they list the VEX.W requirements in the exception classes as well (except
> + * when they don't).  AMD describes class 6 as "AVX Mixed Memory Argument"
> + * without defining what a mixed memory argument is, but still use 4 as the
> + * primary exception class... except when they don't.
> + *
> + * The summary is:
> + *                       Intel     AMD         VEX.W           note
> + * -------------------------------------------------------------------
> + * vpblendd              4         4J          0
> + * vpblendvb             4         4E-X        0               (*)
> + * vpbroadcastq          6         6D          0               (+)
> + * vpermd/vpermps        4         4H          0               (§)
> + * vpermq/vpermpd        4         4H-1        1               (§)
> + * vpermilpd/vpermilps   4         6E          0               (^)
> + * vpmaskmovd            6         4K          significant     (^)
> + * vpsllv                4         4K          significant
> + * vpsrav                4         4J          0
> + * vpsrlv                4         4K          significant
> + * vtestps/vtestpd       4         4G          0
> + *
> + *    (*)  AMD lists VPBLENDVB as related to SSE4.1 PBLENDVB, which may
> + *         explain why it is considered exception class 4.  However,
> + *         Intel says that VEX-only instructions should be in class 6...
> + *
> + *    (+)  Not found in Intel's table 2-16
> + *
> + *    (§)  4H and 4H-1 do not mention VEX.W requirements, which are
> + *         however present in the description of the instruction
> + *
> + *    (^)  these are the two cases in which Intel and AMD disagree on the
> + *         primary exception class

Oof.

Acked-by: Richard Henderson <richard.henderson@linaro.org>


r~