Re: [PATCH 2/3] target/i386/tcg: move validate_vex() before all operand decoding

[Zhao Liu <zhao1.liu@intel.com>]

On Wed, Sep 30, 2026 at 08:54:05AM +0200, Paolo Bonzini wrote:
> Date: Wed, 30 Sep 2026 08:54:05 +0200
> From: Paolo Bonzini <pbonzini@redhat.com>
> Subject: [PATCH 2/3] target/i386/tcg: move validate_vex() before all
>  operand decoding
> X-Mailer: git-send-email 2.55.0
> 
> Operand sizes are computed in decode_insn(), because s->rip_offset has to
> be known before decode_modrm() computes a RIP-relative address.  However,
> validate_vex() runs later and, for X86_VEX_REPScalar instructions, it must
> be able to turn e->s2 into X86_SIZE_ss or X86_SIZE_sd in presence of a
> memory operand.  But right now decode_op_size() has already run, and
> therefore decode->op[2].ot stays MO_128; the instruction therefore
> accesses 16 bytes of memory instead of 4 or 8.
> 
> The only user of s->rip_offset is decode_modrm(), which is called from
> decode_ops(), so the size computation can move there, after validate_vex().
> Thanks to the previous patch, the CR0.TS and CR0.EM checks come after
> decode_ops(), so #UD for an invalid VEX.L still has priority over #NM.
> 
> This way, when validate_vex() adjusts the X86OpEntry, decode_op_size()
> picks up the result.  This behaves as intended by commit b7d4ec4832d
> ("target/i386/tcg: move VEX validation early", 2026-08-26), and fixes
> REPScalar instructions that have a memory operand.
> 
> This also applies to unary operations, which need to ignore VEX.L.
> While this could also be fixed by using "dq" for the operand size, it
> is untidy that simply setting "s->vex_l = 0" does not do the right thing.
> 
> Fixes: b7d4ec4832d ("target/i386/tcg: move VEX validation early", 2026-08-26)
> Reported-by: Zhao Liu <zhao1.liu@intel.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  target/i386/tcg/decode-new.c.inc | 17 +++++++----------
>  1 file changed, 7 insertions(+), 10 deletions(-)

Reviewed-by: Zhao Liu <zhao1.liu@intel.com>