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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/08/16 11:29, Jan Beulich wrote:
>>>> On 10.08.16 at 11:58, <luwei.kang@xxxxxxxxx> wrote:
>>>>>> On 03.08.16 at 03:32, <luwei.kang@xxxxxxxxx> wrote:
>>>>>  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".
>>>> Hi jan, what is your opinion?
>>> There's no opinion to be had here, according to your earlier reply. I do, 
>> however, continue to question that model: State and
>>> instruction set are independent items. Of course YMM state is a prereq to 
>> ZMM state, but I do not buy AVX2 insn support being a
>>> prereq to AVX-512 insns. Yet to me the AVX2 and AVX-512F feature flags 
>>> solely 
>> represent the instructions, while the XSTATE leaf bits
>>> represent the states.
>>>
>> Hi jan,
>>     I get some information from hardware colleague.  There is no dependence 
>> about AVX512 instructions and AVX2 instructions. It is also not states in 
>> the 
>> official document.
> As I had assumed.
>
>>    But I want to know the meaning of the dependence "AVX2: [AVX512F]"  in 
>> "gen-cpuid.py" file. 
>>    If it is the feature dependence, I think the dependence between AVX512 
>> and AVX2  may need to add. As we talk before, Zmm is part of AVX512 feature. 
>> If the state for AVX2 isn't enabled (in XCR0), then AVX512 also can't 
>> function. Apart from that, there is no processors with AVX512  without AVX2 
>> currently and it is safe to treat AVX2 as part of the thermometer leading to 
>> AVX512. Regarding if will have a cpu support avx512 without avx2 in future, 
>> it is really hard to say.
>>     If it is the instructions dependence, I have no idea to delete this 
>> dependence in "gen-cpuid.py" file.
>>     So, I want to know your advice.
> Well, the main issue here is that we have no feature flag representation
> for the xstate bits. If we had, the relevant parts of the dependencies
> should look like
>
>       XSTATE_YMM: [AVX, XSTATE_ZMM]
>       AVX: [AVX2]
>       XSTATE_ZMM: [AVX512F]
>       AVX512F: [AVX512CD, ...]
>
> But in their absence I guess keeping the AVX2 dependency as you have
> it is the only reasonable approach. Just that I'd like it to be accompanied
> by a comment explaining that this isn't the actual dependency (so that if
> XSTATE feature flags got introduced later, it would be clear how to
> adjust those parts).
>
> Andrew - I keep forgetting why you think having such XSTATE_* feature
> flags is not appropriate.

This is all about providing a plausible cpuid layout to a guest.

It is not plausible that we will ever see a processor with e.g. AVX512F
but not XSTATE_ZMM.

Therefore, to avoid that misconfiguration (or the inverse
misconfiguration) from ever occurring, the XSTATE is derived from the
plain feature flags.

~Andrew

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