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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan



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