On 15/06/2022 11:28, Jan Beulich wrote:
> This encoding space is a very sparse clone of the "twobyte" one. Re-use
> that table, as the entries corresponding to invalid opcodes in Map5 are
> simply benign with simd_size forced to other than simd_none (preventing
> undue memory reads in SrcMem
This encoding space is a very sparse clone of the "twobyte" one. Re-use
that table, as the entries corresponding to invalid opcodes in Map5 are
simply benign with simd_size forced to other than simd_none (preventing
undue memory reads in SrcMem handling early in x86_emulate()).
Signed-off-by: Jan