|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 09/25] x86emul: support XOP insns
On 02/02/18 15:17, Jan Beulich wrote:
>>>> On 02.02.18 at 13:03, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 07/12/17 14:04, Jan Beulich wrote:
>>> @@ -8027,6 +8060,13 @@ x86_emulate(
>>> generate_exception_if(vex.w, EXC_UD);
>>> goto simd_0f_imm8_avx;
>>>
>>> + case X86EMUL_OPC_VEX_66(0x0f3a, 0x48): /* vpermil2ps
>>> $imm,{x,y}mm/mem,{x,y}mm,{x,y}mm,{x,y}mm */
>>> + /* vpermil2ps
>>> $imm,{x,y}mm,{x,y}mm/mem,{x,y}mm,{x,y}mm */
>>> + case X86EMUL_OPC_VEX_66(0x0f3a, 0x49): /* vpermil2pd
>>> $imm,{x,y}mm/mem,{x,y}mm,{x,y}mm,{x,y}mm */
>>> + /* vpermil2pd
>>> $imm,{x,y}mm,{x,y}mm/mem,{x,y}mm,{x,y}mm */
>>> + host_and_vcpu_must_have(xop);
>>> + goto simd_0f_imm8_ymm;
>> Is this correct? VEX.W selects which operand may be the memory operand,
>> and I don't see anything in the decode which copes, or anything in the
>> stub which adjusts .W.
> That's the nice thing here - by re-using the original instruction in
> the stub (with only GPR numbers adjusted if necessary) we simply
> don't care which of the operands it the memory one, as long as
> the access width does not differ (and it doesn't).
Hmm - that is very subtle, but ok.
Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> as I didn't find any
other issues with the patch.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |