On 27/05/2019 09:02, Jan Beulich wrote:
>>>> On 24.05.19 at 22:48, <andrew.coop...@citrix.com> wrote:
>> 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.
> And by implication I take it that the L'L=1 and L'L=2 cases indeed to not
> #UD there?
Correct. It would appear that, unhelpfully, the L'L==3 being reserved
rule takes higher precedence than the L'L-is-ignored rule for this class
of instruction.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
