Re: your patch "crypto: sha1 - SSSE3 based SHA1 implementation forx86-64" vs xsave

[Mathias Krause]

On Thu, Nov 17, 2011 at 11:33 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> Mathias,
>
> in avx_usable() you use cpu_has_osxsave to determine whether AVX can
> actually be used, but I can't see how that conditional would ever evaluate
> to true.

Well, it does, at least in my setup, a Core i7-2620M:

  [   44.902613] sha1_ssse3: Using AVX optimized SHA-1 implementation

> Checking CPUID.OSXSAVE is actually a user land requirement,
> whereas in the kernel you should really look at kernel internal variables
> to determine whether xsave was enabled

That's a valid point. I actually ported the check from the initial
assembler implementation which was written with userland code in mind.
Albeit this test can also be used in kernel code because the kernel
only sets this flag after xsave was enabled in
arch/x86/kernel/xsave.c:xstate_enable_boot_cpu/xstate_enable

> (or, if you really want to stay
> with using cpu_has_osxsave you'd have to force re-execution of
> get_cpu_cap() after xsave got enabled on individual CPUs), namely
> mmu_cr4_features having X86_CR4_OSXSAVE set.

I don't see where X86_CR4_OSXSAVE would get reset after xsave init.
Can you give me a pointer to that code?

> Additionally, under a hypervisor, CPUID.OSXSAVE may be set (due to
> the hypervisor having enabled xsave), while the kernel may be running
> with xsave disabled (e.g. due to a command line option saying so).

When noxsave is given on the kernel command line, X86_FEATURE_XSAVE
will be cleared and xsave_init() won't call xstate_enable(), so not
setting X86_CR4_OSXSAVE. All fine.


Thanks,
Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/