Linux 5.0 compat: SIMD compatibility

Restore the SIMD optimization for 4.19.38 LTS, 4.14.120 LTS,
and 5.0 and newer kernels.  This is accomplished by leveraging
the fact that by definition dedicated kernel threads never need
to concern themselves with saving and restoring the user FPU state.
Therefore, they may use the FPU as long as we can guarantee user
tasks always restore their FPU state before context switching back
to user space.

For the 5.0 and 5.1 kernels disabling preemption and local
interrupts is sufficient to allow the FPU to be used.  All non-kernel
threads will restore the preserved user FPU state.

For 5.2 and latter kernels the user FPU state restoration will be
skipped if the kernel determines the registers have not changed.
Therefore, for these kernels we need to perform the additional
step of saving and restoring the FPU registers.  Invalidating the
per-cpu global tracking the FPU state would force a restore but
that functionality is private to the core x86 FPU implementation
and unavailable.

In practice, restricting SIMD to kernel threads is not a major
restriction for ZFS.  The vast majority of SIMD operations are
already performed by the IO pipeline.  The remaining cases are
relatively infrequent and can be handled by the generic code
without significant impact.  The two most noteworthy cases are:

  1) Decrypting the wrapping key for an encrypted dataset,
     i.e. `zfs load-key`.  All other encryption and decryption
     operations will use the SIMD optimized implementations.

  2) Generating the payload checksums for a `zfs send` stream.

In order to avoid making any changes to the higher layers of ZFS
all of the `*_get_ops()` functions were updated to take in to
consideration the calling context.  This allows for the fastest
implementation to be used as appropriate (see kfpu_allowed()).

The only other notable instance of SIMD operations being used
outside a kernel thread was at module load time.  This code
was moved in to a taskq in order to accommodate the new kernel
thread restriction.

Finally, a few other modifications were made in order to further
harden this code and facilitate testing.  They include updating
each implementations operations structure to be declared as a
constant.  And allowing "cycle" to be set when selecting the
preferred ops in the kernel as well as user space.

Reviewed-by: Tony Hutter <[email protected]>
Signed-off-by: Brian Behlendorf <[email protected]>
Closes #8754 
Closes #8793 
Closes #8965 

1 files changed, 29 insertions, 3 deletions

diff --git a/module/icp/io/aes.c b/module/icp/io/aes.c
index 53b193693..51538bc60 100644
--- a/module/icp/io/aes.c
+++ b/module/icp/io/aes.c
@@ -206,9 +206,35 @@ aes_mod_init(void)
 {
 	int ret;
 
-	/* find fastest implementations and set any requested implementations */
-	aes_impl_init();
-	gcm_impl_init();
+#if defined(_KERNEL)
+	/*
+	 * Determine the fastest available implementation.  The benchmarks
+	 * are run in dedicated kernel threads to allow Linux 5.0+ kernels
+	 * to use SIMD operations.  If for some reason this isn't possible,
+	 * fallback to the generic implementations.  See the comment in
+	 * include/linux/simd_x86.h for additional details.  Additionally,
+	 * this has the benefit of allowing them to be run in parallel.
+	 */
+	taskqid_t aes_id = taskq_dispatch(system_taskq, aes_impl_init,
+	    NULL, TQ_SLEEP);
+	taskqid_t gcm_id = taskq_dispatch(system_taskq, gcm_impl_init,
+	    NULL, TQ_SLEEP);
+
+	if (aes_id != TASKQID_INVALID) {
+		taskq_wait_id(system_taskq, aes_id);
+	} else {
+		aes_impl_init(NULL);
+	}
+
+	if (gcm_id != TASKQID_INVALID) {
+		taskq_wait_id(system_taskq, gcm_id);
+	} else {
+		gcm_impl_init(NULL);
+	}
+#else
+	aes_impl_init(NULL);
+	gcm_impl_init(NULL);
+#endif
 
 	if ((ret = mod_install(&modlinkage)) != 0)
 		return (ret);