From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 660FFC433FE for ; Thu, 10 Dec 2020 18:13:27 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0483E23D57 for ; Thu, 10 Dec 2020 18:13:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0483E23D57 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:MIME-Version:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-Id:Date:Subject:To:From:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Owner; bh=nfqXd/HCo0SHSo5Cz35OFI49lK5+G/gUyp8IxOWs6OA=; b=JqxhnjL/942pArJWoeyazgI4Cm +tBHCCIla3U+sCsWHNQGVoY0zx8j1moCyvh00KMiDRGT0LpmBmOzn5oQ3ObuNY+5xAMmCW9akNTOt IgBQiJfv6bUfr5DjpnQw2iV7GQPLZSBdhNg7ec7/FtZlYlBMEfYogYhNXmvCQA343krgobjtiRFw3 7kSa2zpHJ5nbupXFJgmiI1J/tflYDB4KiKvNx0HFdloJAAietDadm2Dw2GKKJ0cPF/wA6x9C7F+J3 zwTvatuCHaUPb1wF3JcgOLe59sX059//3cH7YnroR1RN1QNcH1GLSkLxyi1KgP9Tuc/C4heCpTs0j tMDyJujA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1knQQD-0008G3-Re; Thu, 10 Dec 2020 18:12:09 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1knQQB-0008FC-A7 for linux-arm-kernel@lists.infradead.org; Thu, 10 Dec 2020 18:12:08 +0000 From: Ard Biesheuvel Authentication-Results: mail.kernel.org; dkim=permerror (bad message/signature format) To: linux-crypto@vger.kernel.org Subject: [RFC PATCH 0/3] crypto: ARM - run kernel mode NEON with softirqs disabled Date: Thu, 10 Dec 2020 19:11:55 +0100 Message-Id: <20201210181158.28960-1-ardb@kernel.org> X-Mailer: git-send-email 2.17.1 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201210_131207_453462_26BF9E2D X-CRM114-Status: GOOD ( 14.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Herbert Xu , Ben Greear , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org, Eric Biggers MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org This series is presented in response to the discussion [0] that has been going on on the linux-crypto list regarding the use of SIMD in synchronous skciphers and AEADs, which is problematic if such transforms may be used in softirq context while the SIMD unit is already being used by the kernel in process context as well. This series proposes a way to work around this restriction. It is mainly intended to elicit discussion, so it is based on ARM not x86, which is probably more instructive, given that ARM does not permit SIMD use in softirq context at all (which is changed by patch #1), and also already carries some of these fallbacks that we should be able to remove if these changes work as intended (patches #2 and #3) The primary assumption here is that use of skciphers and AEADs is currently only supported in process or softirq context. If this is true, we can avoid the need for dealing with nested use of the SIMD unit (when softirq uses the SIMD unit while it is already being used in process context), by disabling softirq processing entirely when the NEON unit is enabled for kernel mode use. If this approach works and turns out to be suitable for x86 as well (which will require a separate discussion involving the x86 maintainers), we will probably need to reduce the scope of the kernel_fpu_begin/end blocks to ensure that softirq processing latency is not affected. Given that x86 has recently been updated to drastically reduce the overhead of preserving/ restoring the FPU state, this should not adversely affect performance. [0] https://lore.kernel.org/linux-crypto/20201201194556.5220-1-ardb@kernel.org/ Cc: Eric Biggers Cc: Herbert Xu Cc: Ben Greear Ard Biesheuvel (3): ARM: vfp: allow kernel mode NEON in softirq context crypto: arm/aes-ce - drop non-SIMD fallbacks and SIMD helper crypto: arm/aes-neonbs - drop non-SIMD fallbacks and SIMD helper arch/arm/crypto/aes-ce-glue.c | 84 +------------- arch/arm/crypto/aes-neonbs-glue.c | 119 ++------------------ arch/arm/include/asm/simd.h | 12 ++ arch/arm/vfp/vfpmodule.c | 11 +- 4 files changed, 31 insertions(+), 195 deletions(-) create mode 100644 arch/arm/include/asm/simd.h -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel