| Message ID | 1487588434-4359-3-git-send-email-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 20.02.17 at 12:00, <andrew.cooper3@citrix.com> wrote: > --- a/xen/tools/gen-cpuid.py > +++ b/xen/tools/gen-cpuid.py > @@ -225,9 +225,13 @@ def crunch_numbers(state): > XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES, > AVX, MPX, PKU, LWP], > > - # AVX is taken to mean hardware support for VEX encoded instructions, > - # 256bit registers, and the instructions themselves. Each of these > - # subsequent instruction groups may only be VEX encoded. > + # AVX is taken to mean hardware support for 256bit registers (which in > + # practice depends on the VEX prefix to encode), and the instructions > + # themselves. > + # > + # AVX is not taken to mean support for the VEX prefix itself. > + # VEX-encoded GPR instructions, such as those from the BMI{1,2} sets > + # function fine in the absence of any enabled xstate. > AVX: [FMA, FMA4, F16C, AVX2, XOP], Even if there aren't any EVEX-encoded non-AVX512 instructions so far, I'd prefer the AVX512F entry to get adjusted along the same lines. With that Reviewed-by: Jan Beulich <jbeulich@suse.com> Jan
On 21/02/17 16:40, Jan Beulich wrote: >>>> On 20.02.17 at 12:00, <andrew.cooper3@citrix.com> wrote: >> --- a/xen/tools/gen-cpuid.py >> +++ b/xen/tools/gen-cpuid.py >> @@ -225,9 +225,13 @@ def crunch_numbers(state): >> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES, >> AVX, MPX, PKU, LWP], >> >> - # AVX is taken to mean hardware support for VEX encoded instructions, >> - # 256bit registers, and the instructions themselves. Each of these >> - # subsequent instruction groups may only be VEX encoded. >> + # AVX is taken to mean hardware support for 256bit registers (which in >> + # practice depends on the VEX prefix to encode), and the instructions >> + # themselves. >> + # >> + # AVX is not taken to mean support for the VEX prefix itself. >> + # VEX-encoded GPR instructions, such as those from the BMI{1,2} sets >> + # function fine in the absence of any enabled xstate. >> AVX: [FMA, FMA4, F16C, AVX2, XOP], > Even if there aren't any EVEX-encoded non-AVX512 instructions so > far, I'd prefer the AVX512F entry to get adjusted along the same > lines. Good point. I will update. > With that Reviewed-by: Jan Beulich <jbeulich@suse.com> Thanks, ~Andrew
>>> On 21.02.17 at 17:40, <JBeulich@suse.com> wrote: >>>> On 20.02.17 at 12:00, <andrew.cooper3@citrix.com> wrote: >> --- a/xen/tools/gen-cpuid.py >> +++ b/xen/tools/gen-cpuid.py >> @@ -225,9 +225,13 @@ def crunch_numbers(state): >> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES, >> AVX, MPX, PKU, LWP], >> >> - # AVX is taken to mean hardware support for VEX encoded instructions, >> - # 256bit registers, and the instructions themselves. Each of these >> - # subsequent instruction groups may only be VEX encoded. >> + # AVX is taken to mean hardware support for 256bit registers (which in >> + # practice depends on the VEX prefix to encode), and the instructions >> + # themselves. >> + # >> + # AVX is not taken to mean support for the VEX prefix itself. >> + # VEX-encoded GPR instructions, such as those from the BMI{1,2} sets >> + # function fine in the absence of any enabled xstate. >> AVX: [FMA, FMA4, F16C, AVX2, XOP], > > Even if there aren't any EVEX-encoded non-AVX512 instructions so > far, I'd prefer the AVX512F entry to get adjusted along the same > lines. With that > Reviewed-by: Jan Beulich <jbeulich@suse.com> Actually, one more thing: XOP really has dual meaning (encoding and certain SIMD instructions). Perhaps it would be good to clarify this here too. Jan
On 21/02/17 16:47, Jan Beulich wrote: >>>> On 21.02.17 at 17:40, <JBeulich@suse.com> wrote: >>>>> On 20.02.17 at 12:00, <andrew.cooper3@citrix.com> wrote: >>> --- a/xen/tools/gen-cpuid.py >>> +++ b/xen/tools/gen-cpuid.py >>> @@ -225,9 +225,13 @@ def crunch_numbers(state): >>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES, >>> AVX, MPX, PKU, LWP], >>> >>> - # AVX is taken to mean hardware support for VEX encoded instructions, >>> - # 256bit registers, and the instructions themselves. Each of these >>> - # subsequent instruction groups may only be VEX encoded. >>> + # AVX is taken to mean hardware support for 256bit registers (which in >>> + # practice depends on the VEX prefix to encode), and the instructions >>> + # themselves. >>> + # >>> + # AVX is not taken to mean support for the VEX prefix itself. >>> + # VEX-encoded GPR instructions, such as those from the BMI{1,2} sets >>> + # function fine in the absence of any enabled xstate. >>> AVX: [FMA, FMA4, F16C, AVX2, XOP], >> Even if there aren't any EVEX-encoded non-AVX512 instructions so >> far, I'd prefer the AVX512F entry to get adjusted along the same >> lines. With that >> Reviewed-by: Jan Beulich <jbeulich@suse.com> > Actually, one more thing: XOP really has dual meaning (encoding > and certain SIMD instructions). Perhaps it would be good to clarify > this here too. We don't currently express any dependencies based on XOP, so there is no text about it. As AMD have dropped XOP encoding in their Zen line, I don't expect this will change going forwards. ~Andrew
>>> On 21.02.17 at 17:53, <andrew.cooper3@citrix.com> wrote: > On 21/02/17 16:47, Jan Beulich wrote: >>>>> On 21.02.17 at 17:40, <JBeulich@suse.com> wrote: >>>>>> On 20.02.17 at 12:00, <andrew.cooper3@citrix.com> wrote: >>>> --- a/xen/tools/gen-cpuid.py >>>> +++ b/xen/tools/gen-cpuid.py >>>> @@ -225,9 +225,13 @@ def crunch_numbers(state): >>>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES, >>>> AVX, MPX, PKU, LWP], >>>> >>>> - # AVX is taken to mean hardware support for VEX encoded instructions, >>>> - # 256bit registers, and the instructions themselves. Each of these >>>> - # subsequent instruction groups may only be VEX encoded. >>>> + # AVX is taken to mean hardware support for 256bit registers (which in >>>> + # practice depends on the VEX prefix to encode), and the instructions >>>> + # themselves. >>>> + # >>>> + # AVX is not taken to mean support for the VEX prefix itself. >>>> + # VEX-encoded GPR instructions, such as those from the BMI{1,2} sets >>>> + # function fine in the absence of any enabled xstate. >>>> AVX: [FMA, FMA4, F16C, AVX2, XOP], >>> Even if there aren't any EVEX-encoded non-AVX512 instructions so >>> far, I'd prefer the AVX512F entry to get adjusted along the same >>> lines. With that >>> Reviewed-by: Jan Beulich <jbeulich@suse.com> >> Actually, one more thing: XOP really has dual meaning (encoding >> and certain SIMD instructions). Perhaps it would be good to clarify >> this here too. > > We don't currently express any dependencies based on XOP, so there is no > text about it. Well, I'm referring to the text (and dependency) above. In particular the dependency is meant for the XOP-encoded SIMD insns (which the XOP feature flag represents), not the XOP-encoded GPR ones (which have distinct feature flags, but the naming sadly collides). Jan
On 21/02/17 17:07, Jan Beulich wrote: >>>> On 21.02.17 at 17:53, <andrew.cooper3@citrix.com> wrote: >> On 21/02/17 16:47, Jan Beulich wrote: >>>>>> On 21.02.17 at 17:40, <JBeulich@suse.com> wrote: >>>>>>> On 20.02.17 at 12:00, <andrew.cooper3@citrix.com> wrote: >>>>> --- a/xen/tools/gen-cpuid.py >>>>> +++ b/xen/tools/gen-cpuid.py >>>>> @@ -225,9 +225,13 @@ def crunch_numbers(state): >>>>> XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES, >>>>> AVX, MPX, PKU, LWP], >>>>> >>>>> - # AVX is taken to mean hardware support for VEX encoded instructions, >>>>> - # 256bit registers, and the instructions themselves. Each of these >>>>> - # subsequent instruction groups may only be VEX encoded. >>>>> + # AVX is taken to mean hardware support for 256bit registers (which in >>>>> + # practice depends on the VEX prefix to encode), and the instructions >>>>> + # themselves. >>>>> + # >>>>> + # AVX is not taken to mean support for the VEX prefix itself. >>>>> + # VEX-encoded GPR instructions, such as those from the BMI{1,2} sets >>>>> + # function fine in the absence of any enabled xstate. >>>>> AVX: [FMA, FMA4, F16C, AVX2, XOP], >>>> Even if there aren't any EVEX-encoded non-AVX512 instructions so >>>> far, I'd prefer the AVX512F entry to get adjusted along the same >>>> lines. With that >>>> Reviewed-by: Jan Beulich <jbeulich@suse.com> >>> Actually, one more thing: XOP really has dual meaning (encoding >>> and certain SIMD instructions). Perhaps it would be good to clarify >>> this here too. >> We don't currently express any dependencies based on XOP, so there is no >> text about it. > Well, I'm referring to the text (and dependency) above. In > particular the dependency is meant for the XOP-encoded SIMD > insns (which the XOP feature flag represents), not the XOP-encoded > GPR ones (which have distinct feature flags, but the naming sadly > collides). Which particular feature groups? I could extend that text to say "VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and $X sets..." ~Andrew
>>> On 21.02.17 at 18:12, <andrew.cooper3@citrix.com> wrote: > Which particular feature groups? I could extend that text to say > > "VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and > $X sets..." TBM and LWP. Jan
On 21/02/17 17:17, Jan Beulich wrote: >>>> On 21.02.17 at 18:12, <andrew.cooper3@citrix.com> wrote: >> Which particular feature groups? I could extend that text to say >> >> "VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and >> $X sets..." > TBM and LWP. Ok. Final text reads: # AVX is not taken to mean support for the VEX prefix itself (nor XOP # for the XOP prefix). VEX/XOP-encoded GPR instructions, such as # those from the BMI{1,2}, TBM and LWP sets function fine in the # absence of any enabled xstate. ~Andrew
>>> On 21.02.17 at 18:42, <andrew.cooper3@citrix.com> wrote: > On 21/02/17 17:17, Jan Beulich wrote: >>>>> On 21.02.17 at 18:12, <andrew.cooper3@citrix.com> wrote: >>> Which particular feature groups? I could extend that text to say >>> >>> "VEX/XOP-encoded GPR instructions, such as those from the BMI{1,2} and >>> $X sets..." >> TBM and LWP. > > Ok. Final text reads: > > # AVX is not taken to mean support for the VEX prefix itself (nor XOP > # for the XOP prefix). VEX/XOP-encoded GPR instructions, such as > # those from the BMI{1,2}, TBM and LWP sets function fine in the > # absence of any enabled xstate. Thanks, looks good. Jan
diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py index 5cab6db..6531ca8 100755 --- a/xen/tools/gen-cpuid.py +++ b/xen/tools/gen-cpuid.py @@ -225,9 +225,13 @@ def crunch_numbers(state): XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES, AVX, MPX, PKU, LWP], - # AVX is taken to mean hardware support for VEX encoded instructions, - # 256bit registers, and the instructions themselves. Each of these - # subsequent instruction groups may only be VEX encoded. + # AVX is taken to mean hardware support for 256bit registers (which in + # practice depends on the VEX prefix to encode), and the instructions + # themselves. + # + # AVX is not taken to mean support for the VEX prefix itself. + # VEX-encoded GPR instructions, such as those from the BMI{1,2} sets + # function fine in the absence of any enabled xstate. AVX: [FMA, FMA4, F16C, AVX2, XOP], # CX16 is only encodable in Long Mode. LAHF_LM indicates that the
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> --- xen/tools/gen-cpuid.py | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)