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

Re: [Xen-devel] [PATCH] x86/cpuid: AVX-512 Feature Detection



>>> On 29.06.16 at 11:50, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 29/06/16 03:20, Luwei Kang wrote:
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -235,6 +235,10 @@ def crunch_numbers(state):
>>          # subsequent instruction groups may only be VEX encoded.
>>          AVX: [FMA, FMA4, F16C, AVX2, XOP],
>>  
>> +        # AVX-512 is an extention of AVX2 and it depends on AVX2 available.
>> +        AVX2: [AVX512F, AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD,
>> +                AVX512BW, AVX512VL, AVX512VBMI],
> 
> I think this needs adjusting.  AVX512F is the base feature and
> indication of extra xstate, while all other AVX512 features (e.g.
> AVX512DQ) are explicitly documented not needing to check for AVX512F if
> the AVX512DQ bit is present.

I think the "not" here is wrong? At least my copy (rev 024) requires
all involved feature bits to be checked (see e.g. table 2-2 or the
individual instruction pages).

> I think it wants to look something like:
> 
> # AVX2 is an extension to AVX, providing mainly new integer instructions.
> # In principle, AVX512 only depends on YMM register state, but many AVX2

DYM ZMM register state here?

Jan

> # instructions are extended by AVX512F to 512-bit forms.
> AVX2: [AVX512F],
> 
> # AVX512F is taken to mean hardware support for EVEX encoded instructions,
> # 512bit registers, and the instructions themselves.  All further AVX512
> features
> # are built on top of AVX512F.
> AVX512F: [AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD,
>                  AVX512BW, AVX512VL, AVX512VBMI],
> 
> ~Andrew




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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