>>> On 21.02.17 at 17:40, <jbeul...@suse.com> wrote:
>>>> On 20.02.17 at 12:00, <andrew.coop...@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 <jbeul...@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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
