[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/cpuid: AVX-512 Feature Detection
>>> On 29.06.16 at 11:50, <andrew.cooper3@xxxxxxxxxx> wrote: > On 29/06/16 03:20, Luwei Kang wrote: >> --- a/xen/tools/gen-cpuid.py >> +++ b/xen/tools/gen-cpuid.py >> @@ -235,6 +235,10 @@ def crunch_numbers(state): >> # subsequent instruction groups may only be VEX encoded. >> AVX: [FMA, FMA4, F16C, AVX2, XOP], >> >> + # AVX-512 is an extention of AVX2 and it depends on AVX2 available. >> + AVX2: [AVX512F, AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD, >> + AVX512BW, AVX512VL, AVX512VBMI], > > I think this needs adjusting. AVX512F is the base feature and > indication of extra xstate, while all other AVX512 features (e.g. > AVX512DQ) are explicitly documented not needing to check for AVX512F if > the AVX512DQ bit is present. I think the "not" here is wrong? At least my copy (rev 024) requires all involved feature bits to be checked (see e.g. table 2-2 or the individual instruction pages). > I think it wants to look something like: > > # AVX2 is an extension to AVX, providing mainly new integer instructions. > # In principle, AVX512 only depends on YMM register state, but many AVX2 DYM ZMM register state here? Jan > # instructions are extended by AVX512F to 512-bit forms. > AVX2: [AVX512F], > > # AVX512F is taken to mean hardware support for EVEX encoded instructions, > # 512bit registers, and the instructions themselves. All further AVX512 > features > # are built on top of AVX512F. > AVX512F: [AVX512DQ, AVX512IFMA, AVX512PF, AVX512ER, AVX512CD, > AVX512BW, AVX512VL, AVX512VBMI], > > ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |