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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 25/07/16 07:09, Kang, Luwei wrote:
>>>> First of all - please don't top post.
>>>>
>>>>> What about remove the dependency between AVX2 and AVX512F
>> ( AVX2:
>>>> [AVX512F], ) ?
>>>>
>>>> Yes, that's what I think we want, but we need Andrew's agreement here.
>>>>
>>> Hi Andrew,  what is your opinion ?
>> You are in a better position to answer than me.
>>
>> For a specific instruction which may be VEX and EVEX encoded, is the 
>> circuitry
>> for a specific instruction shared, or discrete?  Is there a plausible future
>> where you might support only the EVEX variant of an instruction, and not the
>> VEX variant?
>>
>> These dependences are about what may be reasonably assumed about the
>> way the environment is structured.  It doesn't look reasonable to advertise
>> an AVX512 environment to guests while at the same time stating that AVX2 is
>> not present.  If this is correct, then the dependency should stay.
>> If Intel plausibly things it might release hardware with !AVX2 but AVX512,
>> then the dependency should be dropped.
> Regarding the dependency between AVX2 and AVX512F, I have ask some hardware 
> architecture engineer.
>
> AVX512 is a superset of AVX2, the most important item being the state. If the 
> state for AVX2 isn't enabled (in XCR0), then AVX512 also can't function.
>
> So if we want to use AVX512, AVX2 must be supported and enabled. The 
> dependence between AVX512F and AVX2 may need be reserved.

Ok, so AVX512 strictly depends on AVX2.

In which case, the python code was correct.  The meaning of the
key/value relationship is "if the feature in the key is not present, all
features in the value must also be disabled".

~Andrew

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