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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B23DEC433EF for ; Mon, 20 Jun 2022 12:43:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :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=0Y30KCdLSbfNdnoJGFNmuHuHK6NPJBv4k3Jm66kp2RI=; b=XDmNDgku6HiKjT YYWptx7QiDmw9irs8+55sWYLFtCaueFdiSwXYSAjUKoD1VgsqT624FOyUPpF2tazi8CjVor/s2P3/ kNX4CA7562wxbBy1yj7KYQv4rPhawqCFtIAwRvBAwemnVIWn7ldL/b3uy4R6pqOnnb3D6M8odHA7n oBLUdAeLow7tDXSc6mZaj5dLTpHq3osaeYVLG7YB351kI4ls6hwM1F4l6gZxGUsdwMEksGVkj9T4d TVZ6O3B57WtHARRF8OH4nK2BxE1drwm5Zp4wb2GGBzDLUbbk4ZpY00RWYLiL4ByOfm5t98TAw5+1D qQAc95i9sd/bFzC4sTVw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o3GjS-000Uu8-T1; Mon, 20 Jun 2022 12:42:18 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o3GjP-000Usy-Ja for linux-arm-kernel@lists.infradead.org; Mon, 20 Jun 2022 12:42:17 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6BF56B81145; Mon, 20 Jun 2022 12:42:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7082C3411B; Mon, 20 Jun 2022 12:42:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655728932; bh=XzH1bHIjCEQTsR3/9eI6H7Suf2gm7bYmxSmt8xZueL0=; h=From:To:Cc:Subject:Date:From; b=sdGANufdTnKlxley5Jz3UDZCCoo/CjR6FTrB4TPOgozj4FVX045gd0ZegjaUCqbPk a2Hhp6kqHb55gE6T+sTcCn1tadio5fhxJoBSPwTojb7L+X8fA/ietCJ+rss5rYmLVN nsJplyqZS86meFflhLqg4tc9HxY9/rbF+xb31rznCqREy+Io+ZT2CmyuJPf4gLzavL mUK0cZCO82NGEwBr785aEkJWHlhcAUs7OTst/7F0tK1yANMfd27l/7F3P049ddLHjX kES+mSizf8W25xxbZrNKllQlhviueSPAkzfuW3YqGNqLzGHOnFzMkjB9ZUdnNlYpgZ HXkPwNvJMrqYw== From: Mark Brown To: Catalin Marinas , Will Deacon Cc: Marc Zyngier , Zhang Lei , James Morse , Alexandru Elisei , Andre Przywara , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Mark Brown Subject: [PATCH v2 0/7] arm64/sve: Clean up KVM integration and optimise syscalls Date: Mon, 20 Jun 2022 13:41:51 +0100 Message-Id: <20220620124158.482039-1-broonie@kernel.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3608; h=from:subject; bh=XzH1bHIjCEQTsR3/9eI6H7Suf2gm7bYmxSmt8xZueL0=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBisGsNIgLKqM2gYzZ+CD7ZYH1hEnzUYnBRIT35ywmR vNCZd26JATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCYrBrDQAKCRAk1otyXVSH0LPDB/ 0YJYU6N0u9Bti/TuAAvnm2GZksQWNh4rBVradci05uxJbIseuoYCt+/fwHbBZqV1pni9cIUKLxuaai 3Kg5OTKWyX1Il8mltaXBQD8KWV8TYnBU0BVyl/T65JyXHeoiqJwEb8GZrjvha3O9Y0onegDr8w9g+w q0XrGYG9bBwpi8kZF/ulhLVXXLAwDcyrVPvQ5FvwxJXn2Y9kCzglYtBa9j+tCbSay96HoQ+QyMuryr z1bmTpu49NnUVxTCZHMEcagKADs8J9aOMW5s+yh0x6vn6mSr+3IKYqAEpozOd5nvYK9b05d4sNu9mu aSRYc7xbCJAPhLupa1eLjsxWbYN6fs X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220620_054215_977399_FEBDD99C X-CRM114-Status: GOOD ( 24.21 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 patch series attempts to clarify the tracking of which set of floating point registers we save on systems supporting SVE, particularly with reference to KVM, and then uses the results of this clarification to improve the performance of simple syscalls where we return directly to userspace in cases where userspace is using SVE. At present we track which register state is active by using the TIF_SVE flag for the current task which also controls if userspace is able to use SVE, this is reasonably straightforward if limiting but for KVM it gets a bit hairy since we may have guest state loaded in registers. This results in KVM modifying TIF_SVE for the VMM task while the guest is running which doesn't entirely help make things easy to follow. To help make things clearer the series changes things so that in addition to TIF_SVE we explicitly track both the type of registers that are currently saved in the task struct and the type of registers that we should save when we do so. TIF_SVE then solely controls if userspace can use SVE without trapping, it has no function for KVM guests and we can remove the code for managing it from KVM. The refactoring to add the separate tracking is initially done by adding the new state together with checks that the state corresponds to expectations when we look at it before subsequent patches make use of the separated state, the goal being to both split out the more repetitive bits of tha change and make it easier to debug any problems that might arise. With the state tracked separately we then start to optimise the performance of syscalls when the process is using SVE. Currently every syscall disables SVE for userspace which means that we need to trap to EL1 again on the next SVE instruction, flush the SVE registers, and reenable SVE for EL0, creating overhead for tasks that mix SVE and syscalls. We build on the above refactoring to eliminate this overhead for simple syscalls which return directly to userspace by: - Keeping SVE enabled. - Not flushing the SVE state. The removal of flushing is within our currently documented ABI but is a change in our effective ABI so a sysctl is provided to revert to current behaviour in case of problems or to allow testing of userspace. If we don't want to do this I think we should tighten our ABI documentation, previously Catalin had indicated that he didn't want to tighten it. v2: - Rebase onto v5.19-rc3. - Don't warn when restoring streaming mode SVE without TIF_SVE. Mark Brown (7): KVM: arm64: Discard any SVE state when entering KVM guests arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE arm64/fpsimd: Have KVM explicitly say which FP registers to save arm64/fpsimd: Stop using TIF_SVE to manage register saving in KVM arm64/fpsimd: Load FP state based on recorded data type arm64/sve: Leave SVE enabled on syscall if we don't context switch arm64/sve: Don't zero non-FPSIMD register state on syscall by default arch/arm64/include/asm/fpsimd.h | 4 +- arch/arm64/include/asm/kvm_host.h | 1 + arch/arm64/include/asm/processor.h | 7 ++ arch/arm64/kernel/fpsimd.c | 131 ++++++++++++++++++++++++----- arch/arm64/kernel/process.c | 2 + arch/arm64/kernel/ptrace.c | 6 +- arch/arm64/kernel/signal.c | 3 + arch/arm64/kernel/syscall.c | 53 +++++++++--- arch/arm64/kvm/fpsimd.c | 16 ++-- 9 files changed, 179 insertions(+), 44 deletions(-) base-commit: a111daf0c53ae91e71fd2bfe7497862d14132e3e -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel