Re: [Xen-devel] [PATCH v8 44/50] x86emul: support VPCLMULQDQ insns

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.06.19 at 14:52, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 15/03/2019 11:05, Jan Beulich wrote:
>> As to the feature dependency adjustment, while strictly speaking AVX is
>> a sufficient prereq (to have YMM registers), 256-bit vectors of integers
>> have got fully introduced with AVX2 only. Sadly gcc can't be used as a
>> reference here: They don't provide any AVX512-independent built-in at
>> all.
>>
>> Along the lines of PCLMULQDQ, since the insns here and in particular
>> their memory access patterns follow the usual scheme, I didn't think it
>> was necessary to add a contrived test specifically for them, beyond the
>> Disp8 scaling one.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> TBD: Should VPCLMULQDQ also depend on PCLMULQDQ?
> 
> I think so, yes.  These are all 64 by 64 multiplies with a 128 bit
> result, and an imm8 to choose which quadwords get used, so both these
> features will be using the silicon block in the vector pipeline.  The
> only difference is whether its wired through from the legacy SSE
> instructions, or the [E]VEX instructions.
> 
> I certainly don't expect to ever see hardware with VPCLMULQDQ but
> lacking PCLMULQDQ.

Okay, will do, and I'll assume that ...

>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cpuid.py
>> @@ -255,8 +255,9 @@ def crunch_numbers(state):
>>  
>>          # This is just the dependency between AVX512 and AVX2 of XSTATE
>>          # feature flags.  If want to use AVX512, AVX2 must be supported and
>> -        # enabled.
>> -        AVX2: [AVX512F],
>> +        # enabled.  Certain later extensions, acting on 256-bit vectors of
>> +        # integers, better depend on AVX2 than AVX.
>> +        AVX2: [AVX512F, VPCLMULQDQ],
> 
> Hmm - this is awkward, because in practice, there won't be any hardware
> in existence with VPCLMULQDQ and AVX2 but lacking AVX512.
> 
> However, the VEX encoding is legitimate in the absence of the EVEX
> encoding, and doesn't depend on the AVX512 XCR0 state.
> 
> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

... this is meant for a patch with that addition to the dependency tree.

Btw - for GFNI and its VEX/EVEX forms this gets even more interesting.
It didn't even occur to me that there could be new hardware supporting
GFNI but no AVX* whatsoever, but I've been told the current split
between SDM and ISA extensions doc is to reflect exactly this.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel