Re: [Xen-devel] [PATCH v8 09/50] x86emul: support AVX512{F, BW} integer unpack insns

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 18/03/2019 09:55, Jan Beulich wrote:
>>>> On 15.03.19 at 19:21, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 15/03/2019 10:41, Jan Beulich wrote:
>>> @@ -6681,6 +6681,12 @@ x86_emulate(
>>>      case X86EMUL_OPC_EVEX_66(0x0f, 0xf6): /* vpsadbw 
>>> [xyz]mm/mem,[xyz]mm,[xyz]mm */
>>>          generate_exception_if(evex.opmsk, EXC_UD);
>>>          /* fall through */
>>> +    case X86EMUL_OPC_EVEX_66(0x0f, 0x60): /* vpunpcklbw 
>>> [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
>>> +    case X86EMUL_OPC_EVEX_66(0x0f, 0x61): /* vpunpcklwd 
>>> [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
>>> +    case X86EMUL_OPC_EVEX_66(0x0f, 0x68): /* vpunpckhbw 
>>> [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
>>> +    case X86EMUL_OPC_EVEX_66(0x0f, 0x69): /* vpunpckhwd 
>>> [xyz]mm/mem,[xyz]mm,[xyz]mm{k} */
>>> +        op_bytes = 16 << evex.lr;
>>> +        /* fall through */
>> If this setting of op_bytes is safe to do for vpsadbw, how does the
>> emulation currently work?
> The setting is redundant for VPSADBW (there it gets set by virtue
> of its table entry saying simd_packed_int), but it's necessary for
> VUNPCK* as their table entries use simd_other, which is necessary
> because of the memory access pattern of PUNPCKL*. In fact the
> PUNPCKH* entries could equally well use simd_packed_int, but
> that would then call for their case labels to get moved away from
> the PUNPCKL* ones, and I slightly prefer them to be kept together.

Ok.

Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

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