[Xen-devel] Ping: Re: [PATCH] x86/cpuid: correct dependencies of post-SSE ISA extensions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.19 at 13:48, <JBeulich@xxxxxxxx> wrote:
>>>> On 14.01.19 at 13:00, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 14/01/2019 11:39, Jan Beulich wrote:
>>> First of all a PCLMULQDQ dependency was missing entirely. Add it as well
>>> as AESNI and SHA to SSE2, as all of them act on vectors of integers,
>>> whereas plain SSE supports vectors of single precision floats only. This
>>> is in line with how e.g. binutils and gcc treat them.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> ---
>>> TBD: On the same basis, SSE3, SSSE3 and SSE4A should probably also
>>> depend on SSE2 rather than SSE. In fact making this a chain SSE -> SSE2
>>> -> SSE3 -> { SSSE3, SSE4A } would probably be best, and get us in line
>>> with both binutils and gcc. But I think I did suggest so when the
>>> dependencies were introduced, and this wasn't liked for a reason I
>>> forgot.
>> 
>> While all of this is true, there is a comment in context which explains
>> why the dependences are they way they are.
>> 
>> Providing a guest with SSE, no SSE2, and PCLMULDQ/AESNI/SHA will allow
>> these latter instruction groups to function correctly.
> 
> You mean "Several futher instruction sets are built on core %XMM
> support, without specific inter-dependencies"? This explains it at
> best partly, the more that there then are exceptions to this rule
> ({,S}SSE3 -> SSE4.1 and SSE4.1 -> SSE4.2). Do we really have to
> take a different view here than binutils and gcc (and perhaps many
> others) do?
> 
> Some of Linux'es x86-specific crypto drivers make even more
> interesting implications, several of which I mean to fix. But they
> (imo) validly imply e.g. SSE2 when there is SSSE3, which would
> mean such a driver would only work because we can't hide the
> SSE2 insns when a guest config file masks off SSE2 but not
> SSSE3 - until such an insn hits the emulator, where the
> vcpu_has_sse2() check would make it raise #UD, just because
> of our non-standard feature dependencies.

Can we try to settle this disagreement please? I can certainly
break out the change to add the PCLMULDQ dependency, but
adding it alongside AESNI and SHA to only depend on SSE
continues to seem wrong to me. I hope you understand that it
doesn't feel well to post a patch which I think (at least for now)
is not correct (as per above, at the very least potentially
misleading for guests).

Jan



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