[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 3/6] x86emul: support AVX512 opmask insns



>>> On 03.09.18 at 19:57, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 29/08/18 15:24, Jan Beulich wrote:
>> These are all VEX encoded, so the EVEX decoding logic continues to
>> remain unused at this point.
>>
>> The new testcase is deliberately coded in assembly, as a C one would
>> have become almost unreadable due to the overwhelming amount of
>> __builtin_...() that would need to be used. After all the compiler has
>> no underlying type (yet) that could be operated on without builtins,
>> other than the vector types used for "normal" SIMD insns.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -6002,6 +6023,60 @@ x86_emulate(
>>              dst.val = src.val;
>>          break;
>>  
>> +    case X86EMUL_OPC_VEX(0x0f, 0x4a):    /* kadd{w,q} k,k,k */
>> +        if ( !vex.w )
>> +            host_and_vcpu_must_have(avx512dq);
> 
> Why is this kadd handled differently?  As far as I can tell from the
> manual, its encoding looks to be consistent.

It's not the encoding, but the AVX512DQ property of kaddw
which other k<op>w insns don't have (those all are AVX512F).

Jan



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.