On 24/05/2019 07:43, Jan Beulich wrote:
>>>> On 23.05.19 at 18:15, <andrew.coop...@citrix.com> 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 <jbeul...@suse.com>
>> Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
> 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.
Ok. Given a test program of:
{
printf("Real:\n");
asm volatile ("vrcp14sd %xmm0,%xmm0,%xmm0");
printf("Bytes:\n");
asm volatile (".byte 0x62, 0xf2, 0xfd, 0x08, 0x4d, 0xc0");
printf("Bad 0x28:\n");
asm volatile (".byte 0x62, 0xf2, 0xfd, 0x28, 0x4d, 0xc0");
printf("Bad 0x48:\n");
asm volatile (".byte 0x62, 0xf2, 0xfd, 0x48, 0x4d, 0xc0");
printf("Bad 0x68:\n");
asm volatile (".byte 0x62, 0xf2, 0xfd, 0x68, 0x4d, 0xc0");
}
Then the L'L = 3 case (0x68 at the end) does indeed take #UD for both
KNL and KNM.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
