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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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