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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan



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