On 21/02/17 16:47, Jan Beulich wrote:
>>>> 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.
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
