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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan

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