Re: [PATCH 02/10] x86/gen-cpuid: Clarify the intended meaning of AVX wrt feature dependencies

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 02/10] x86/gen-cpuid: Clarify the intended meaning of AVX wrt feature dependencies
Date: Tue, 21 Feb 2017 17:12:36 +0000	[thread overview]
Message-ID: <897e2846-8b28-ac5a-692f-57ff89ab30f4@citrix.com> (raw)
In-Reply-To: <58AC81EC020000780013C616@prv-mh.provo.novell.com>

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

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