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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.02.17 at 17:53, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 21/02/17 16:47, Jan Beulich wrote:
>>>>> On 21.02.17 at 17:40, <JBeulich@xxxxxxxx> wrote:
>>>>>> On 20.02.17 at 12:00, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxx>
>> 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


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