Re: [Xen-devel] [PATCH v8 27/50] x86emul: support AVX512{F, ER} reciprocal insns

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.05.19 at 18:15, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 15/03/2019 10:55, Jan Beulich wrote:
>> Also include the only other AVX512ER insn pair, VEXP2P{D,S}.
>>
>> Note that despite the replacement of the SHA insns' table slots there's
>> no need to special case their decoding: Their insn-specific code already
>> sets op_bytes (as was required due to simd_other), and TwoOp is of no
>> relevance for legacy encoded SIMD insns.
>>
>> The raising of #UD when EVEX.L'L is 3 for AVX512ER scalar insns is done
>> to be on the safe side. The SDM does not clarify behavior there, and
>> it's even more ambiguous here (without AVX512VL in the picture).
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

Thanks, also for the others.

> Seeing as I have some ER hardware, is there an easy way to get
> GCC/binutils to emit a weird L'L field, or will this involve some manual
> opcode generation to test?

gcc does not provide any control at all, afaict. binutils allows "weird"
VEX.L or EVEX.L'L only for insns it believes ignore that field. So yes,
I'm afraid this will involve using .byte.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel