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@lists.xen.org https://lists.xen.org/xen-devel
