On 14/01/2019 12:48, Jan Beulich wrote:
>>>> On 14.01.19 at 13:00, <andrew.coop...@citrix.com> 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 <jbeul...@suse.com>
>>> ---
>>> 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.The dependences described here are primarily to prevent malfunctions in Xen, rather than to provide a historically-accurate view of which features appeared when. Software which doesn't follow the rules cannot be helped - its already buggy. The question which matters here is whether the Intel/AMD SDM's allow for any such implications. Vol1 12.13.4 states that software wishing to use AES-NI or PCMULDQ must first check for SSE2, and then for the individual feature bit. I suppose this is better evidence of a logical connection than we've used in other bits of the dependency tree, but I see absolutely nothing discussing the SHA instruction set. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
