Re: [PATCH v2 9/9] x86emul: support AVX10.2 256-bit embedded rounding / SAE

[Jan Beulich <jbeulich@xxxxxxxx>]

On 14.08.2024 10:54, Jan Beulich wrote:
> AVX10.2 (along with APX) assigns new meaning to the bit that previsouly
> distinguished EVEX from the Phi co-processor's MVEX. Therefore
> evex_encoded() now needs to key off of something else: Use the opcode
> mapping field for this, leveraging that map 0 has no assigned opcodes
> (and appears unlikely to gain any).
> 
> Place the check of EVEX.U such that it'll cover all insns. EVEX.b is
> being checked for individual insns as applicable - whenever that's valid
> for (register-only) 512-bit forms, it becomes valid for 256-bit forms as
> well when AVX10.2 is permitted for a guest.

This isn't quite right: For scalar insns EVEX.U needs to be consistently
set[1]. There's no pattern though to easily identify them all, so it'll be
tedious / error prone to add checks in all necessary places.

Jan

[1] That's my expectation at least. The spec lacks the necessary details.
(The exception classes say "EVEX.b encoding #UD conditions not met." Yet
an update to the respective table in the SDM isn't provided.) But in the
absence of a clear statement that the bit would be ignore for scalar
insns, we need to assume that it being wrongly clear would / should cause
#UD.