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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.05.19 at 22:48, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 24/05/2019 07:43, Jan Beulich wrote:
>>>>> 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.
> 
> 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.

And by implication I take it that the L'L=1 and L'L=2 cases indeed to not
#UD there?

Thanks for having tried this out,
Jan



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