On 18/03/2019 09:55, Jan Beulich wrote: >>>> On 15.03.19 at 19:21, <[email protected]> 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 <[email protected]> _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
