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

["Kang, Luwei" <luwei.kang@xxxxxxxxx>]

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

> 
> ~Andrew

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