From patchwork Thu Jul 20 18:38:58 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 13320989 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 C82F5EB64DA for ; Thu, 20 Jul 2023 18:39:35 +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:Cc:To:In-Reply-To:References:Message-Id :MIME-Version:Subject:Date:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=SpD0zeCEbkTSevXTQb4Sa2wMO2IbRpAd7fT6SDZA3l4=; b=OoT8VEyyVEu9V8 LlCqTt5KbhFip2pVmZs2FaOlxqJt7r036OIJXxks5Kcltyb3VtjMA0bAuZ0vBb3O8kdwt4WC55cAo FHN1uLwYkPPjK6v9peslkSF04kw+4i3UDgA/XsWrgc1eDoZQ0R4g0fpmeDV/6NM3GAJZdKeU3aECE 62JSDwDD7aS8qOOIDX10mIZ6C4qgUlLHsu/PRK6qKd/OoKrLw1N5h7MJA757ygq9vUTAKRPNUIKRf 2bUvQf/UVKfCruKi7aCZNsQE1pY59omti12sxd/9QLLEX2rM72OGq45zPpw+mwSZcITniFn2vW4JB 3gQt2K3EBsvDOMyZ0IFw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qMYYZ-00BuwI-0d; Thu, 20 Jul 2023 18:39:19 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qMYYR-00ButU-2R for linux-arm-kernel@lists.infradead.org; Thu, 20 Jul 2023 18:39:13 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3BEB261BF8; Thu, 20 Jul 2023 18:39:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1B13C433CC; Thu, 20 Jul 2023 18:39:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689878350; bh=cJdsEMWu4Vw4UDfbXEhrIi77kKUyxBMQ+oaGSCuCK3E=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=YZkcJhFTmw1HPNCUbq/w1IfKEsEptFEJD1W2JPuwWxGr7tFO9SQCTfZMaEDtHuq8l e4zUx/zO+3w1TccNL5Y+8tenapCYOzqcq6IKH+pa2I0q5vpqoCTRcN3Rlf7hqUl2Lb Fcs6Fw1RgUL1heKymdHm3vK1/IkTiXJkJgqFjQR1hMijVuVwprGZ02lV7O0s9EHviS 1tJu7D1NntfhigBfbxuXejuLWgegfJDnIpnnSS+OGTI+rvKuIe1OrOmwg0BaZcwPVz SDFuCMKGoQa75D8SWoNqk6tzkMO6XEa1p6cPZjyMWqcGLUL/KwnISz/HWfVhEjTzW+ m5LAliREjPL+Q== From: Mark Brown Date: Thu, 20 Jul 2023 19:38:58 +0100 Subject: [PATCH v2 1/3] arm64/fpsimd: Ensure SME storage is allocated after SVE VL changes MIME-Version: 1.0 Message-Id: <20230720-arm64-fix-sve-sme-vl-change-v2-1-8eea06b82d57@kernel.org> References: <20230720-arm64-fix-sve-sme-vl-change-v2-0-8eea06b82d57@kernel.org> In-Reply-To: <20230720-arm64-fix-sve-sme-vl-change-v2-0-8eea06b82d57@kernel.org> To: Catalin Marinas , Will Deacon , Shuah Khan Cc: David Spickett , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Mark Brown , stable@vger.kernel.org X-Mailer: b4 0.13-dev-099c9 X-Developer-Signature: v=1; a=openpgp-sha256; l=3126; i=broonie@kernel.org; h=from:subject:message-id; bh=cJdsEMWu4Vw4UDfbXEhrIi77kKUyxBMQ+oaGSCuCK3E=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBkuX9H8a1ZEjatBHUy3+YyrBKN9Ns5zmE97HZq59se mG1hfjuJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZLl/RwAKCRAk1otyXVSH0BFLB/ 48MuNQeHejkUjg+G0TolCglEKFMd2HtiKuI+aYs/va+ARg5B5tGns4k2GfNlWF3F3MncLnUHAh6pi0 uoZE8qR/HEHBQHh4ls8cAgx+zwm0BKVdRn85HEjCBA64N9Acm6AxpYS7OqZSq5gf736VUDI3tv0kTW hGf7qZpF95H28Wey0JMlDoHhmIgbniieL0gyklP4t5Zdvo0YwF79VKAXd1Ck/CB6G4kQLhcWvN94tU s9H+8v0mJHQjSzZntWYNYoFykVM1cQjTzmnXhyKy6USVDT1HWfVoPq6b6IhcfgTCMLvL6GxSCurZAz 3ee2zR926o69yQ3TBwXC2+a2sbrtUw 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-20230720_113911_877162_F795B6CF X-CRM114-Status: GOOD ( 18.98 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org When we reconfigure the SVE vector length we discard the backing storage for the SVE vectors and then reallocate on next SVE use, leaving the SME specific state alone. This means that we do not enable SME traps if they were already disabled. That means that userspace code can enter streaming mode without trapping, putting the task in a state where if we try to save the state of the task we will fault. Since the ABI does not specify that changing the SVE vector length disturbs SME state, and since SVE code may not be aware of SME code in the process, we shouldn't simply discard any ZA state. Instead immediately reallocate the storage for SVE, and disable SME if we change the SVE vector length while there is no SME state active. Disabling SME traps on SVE vector length changes would make the overall code more complex since we would have a state where we have valid SME state stored but might get a SME trap. Fixes: 9e4ab6c89109 ("arm64/sme: Implement vector length configuration prctl()s") Reported-by: David Spickett Signed-off-by: Mark Brown Cc: stable@vger.kernel.org --- arch/arm64/kernel/fpsimd.c | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 7a1aeb95d7c3..89d54a5242d1 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -847,6 +847,8 @@ void sve_sync_from_fpsimd_zeropad(struct task_struct *task) int vec_set_vector_length(struct task_struct *task, enum vec_type type, unsigned long vl, unsigned long flags) { + bool free_sme = false; + if (flags & ~(unsigned long)(PR_SVE_VL_INHERIT | PR_SVE_SET_VL_ONEXEC)) return -EINVAL; @@ -897,21 +899,36 @@ int vec_set_vector_length(struct task_struct *task, enum vec_type type, task->thread.fp_type = FP_STATE_FPSIMD; } - if (system_supports_sme() && type == ARM64_VEC_SME) { - task->thread.svcr &= ~(SVCR_SM_MASK | - SVCR_ZA_MASK); - clear_thread_flag(TIF_SME); + if (system_supports_sme()) { + if (type == ARM64_VEC_SME || + !(task->thread.svcr & (SVCR_SM_MASK | SVCR_ZA_MASK))) { + /* + * We are changing the SME VL or weren't using + * SME anyway, discard the state and force a + * reallocation. + */ + task->thread.svcr &= ~(SVCR_SM_MASK | + SVCR_ZA_MASK); + clear_thread_flag(TIF_SME); + free_sme = true; + } } if (task == current) put_cpu_fpsimd_context(); /* - * Force reallocation of task SVE and SME state to the correct - * size on next use: + * Free the changed states if they are not in use, SME will be + * reallocated to the correct size on next use and we just + * allocate SVE now in case it is needed for use in streaming + * mode. */ - sve_free(task); - if (system_supports_sme() && type == ARM64_VEC_SME) + if (system_supports_sve()) { + sve_free(task); + sve_alloc(task, true); + } + + if (free_sme) sme_free(task); task_set_vl(task, type, vl); From patchwork Thu Jul 20 18:38:59 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 13320990 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 6975AEB64DD for ; Thu, 20 Jul 2023 18:39:41 +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:Cc:To:In-Reply-To:References:Message-Id :MIME-Version:Subject:Date:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=MEqB0GqSg4mdmyJ2geVqHLkNFv7gWwbkY2QbwGDrBV0=; b=qBGlewAdoBDcEj EUJPaDqYxnbfuWeYyjgT+ciZDak3v4aip5objeLbxrLFVvMG/EsFFIFfEUwsD/1MEMAuAEqau3ydV Vku5/SARZxr7SV/c8DGyh3DtR3LhBAOddX7aapOQ34Q4Bq2RMFCLpBYjWp7RJ0oZMwj+b5B2O7SHl 8Y+9LGpLW7TPNsK7mcLo2jlw50NvXVgRsqhUdGxRYe9CeKktgwViTpZ9XHmULRJ/+tpd3+5g4HhVj 6OqD+byRdkRiI19oQjmshJ/iAlbO1NOqnp87xk6FbTM6IxTKtCkbo8NYs8UXAf4sYlC24uV1nwa3w KwavSNhnpEXlt0pHktBw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qMYYZ-00Buwj-2B; Thu, 20 Jul 2023 18:39:19 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qMYYV-00BuuU-16 for linux-arm-kernel@lists.infradead.org; Thu, 20 Jul 2023 18:39:16 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DA81561BD4; Thu, 20 Jul 2023 18:39:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 413BEC433CB; Thu, 20 Jul 2023 18:39:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689878354; bh=pefhisUmRsg+2EzyXrIeOHRp6qKwWRumC3ginNtyGbg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=p/oJ6uyxh3xofibC1pEqoM1PeEC5/+oMzPMezdcSijS3RdbpERHzTz5LwehzW8Vet SkBQdrctNCfcunPCiQ7idJY41da67z2cWB2d5x5d8QqJGYuuUyoPd2vFgjk+VzCoQd pt6bBi+PoZQ7W+E6JKFgVEkyag4ySlImLRcSR7gZYLn66vVausxBrhbcGO9UHw6AsW fkQvvGKFpJu+XFE8cxJ/aUErjgj8lNFV+394YWt5b9CdZptacC40p74U2yvpfnc9es sXUzmIf/PD8lqrZoN4lgRqKjqzAX5d7kiMBkNYJOb7w4KEFyLiq+Ve0hTqWevE0VDw woeprbJI/RYRQ== From: Mark Brown Date: Thu, 20 Jul 2023 19:38:59 +0100 Subject: [PATCH v2 2/3] kselftest/arm64: Add a test case for SVE VL changes with SME active MIME-Version: 1.0 Message-Id: <20230720-arm64-fix-sve-sme-vl-change-v2-2-8eea06b82d57@kernel.org> References: <20230720-arm64-fix-sve-sme-vl-change-v2-0-8eea06b82d57@kernel.org> In-Reply-To: <20230720-arm64-fix-sve-sme-vl-change-v2-0-8eea06b82d57@kernel.org> To: Catalin Marinas , Will Deacon , Shuah Khan Cc: David Spickett , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Mark Brown X-Mailer: b4 0.13-dev-099c9 X-Developer-Signature: v=1; a=openpgp-sha256; l=4758; i=broonie@kernel.org; h=from:subject:message-id; bh=pefhisUmRsg+2EzyXrIeOHRp6qKwWRumC3ginNtyGbg=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBkuX9IrtjQMya+hnrdUq/tdc/QlegceKFWcKxurFj5 FT9G+faJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZLl/SAAKCRAk1otyXVSH0NHrB/ 9bQANLHG6b9UnQm/WjRfWZOiAjyBfrksGMqOKKJr+/uNan8IR/2wuGJCJ8Rv/nMzUgIIyC8SF/XziY 983Mk6LYgev8A+0ZxyyLjR8r1HAAuJB6+Q5T4WI8Nx3xEgpKpLM7tPAqDkHkdkfMyONObCRYv0Qern jot3GNH19btOoM/v16hCL5wuYwWDXXtSaHtBrvVva+8SCl5GiVeBFTNYDm86PwAGNWZJca+Vl1Uc+6 TlpTOwbAwuCLg8qrRAe5uDtPJD+O3CLSMqBDxZGWN02ys0X1c55v4qAetgs7itHwyyKmdX5tQ7wXUb YJnDKspvNKrPW+ciek5wgmRjyikEs0 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-20230720_113915_465493_98378638 X-CRM114-Status: GOOD ( 24.85 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org We just fixed an issue where changing the SVE VL while SME was active could result in us attempting to save the streaming mode SVE vectors without any backing storage. Add a test case which provokes that issue, ideally we should also verify that the contents of ZA are unaffected by any of what we did. Note that since we need to keep streaming mode enabled we can't use any syscalls to trigger the issue, we have to sit in a loop in usersapce and hope to be preempted. The chosen numbers trigger with defconfig on all the virtual platforms for me, this won't be 100% on all systems but avoid an overcomplicated test implementation. Signed-off-by: Mark Brown --- tools/testing/selftests/arm64/fp/vec-syscfg.c | 105 +++++++++++++++++++++++++- 1 file changed, 102 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/arm64/fp/vec-syscfg.c b/tools/testing/selftests/arm64/fp/vec-syscfg.c index 9bcfcdc34ee9..58ea4bde5be7 100644 --- a/tools/testing/selftests/arm64/fp/vec-syscfg.c +++ b/tools/testing/selftests/arm64/fp/vec-syscfg.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include #include @@ -39,9 +40,11 @@ struct vec_data { int max_vl; }; +#define VEC_SVE 0 +#define VEC_SME 1 static struct vec_data vec_data[] = { - { + [VEC_SVE] = { .name = "SVE", .hwcap_type = AT_HWCAP, .hwcap = HWCAP_SVE, @@ -51,7 +54,7 @@ static struct vec_data vec_data[] = { .prctl_set = PR_SVE_SET_VL, .default_vl_file = "/proc/sys/abi/sve_default_vector_length", }, - { + [VEC_SME] = { .name = "SME", .hwcap_type = AT_HWCAP2, .hwcap = HWCAP2_SME, @@ -644,18 +647,107 @@ static const test_type tests[] = { prctl_set_all_vqs, }; +static inline void smstart(void) +{ + asm volatile("msr S0_3_C4_C7_3, xzr"); +} + +static inline void smstart_sm(void) +{ + asm volatile("msr S0_3_C4_C3_3, xzr"); +} + +static inline void smstop(void) +{ + asm volatile("msr S0_3_C4_C6_3, xzr"); +} + + +/* + * Verify we can change the SVE vector length while SME is active and + * continue to use SME afterwards. + */ +static void change_sve_with_za(void) +{ + struct vec_data *sve_data = &vec_data[VEC_SVE]; + bool pass = true; + int ret, i; + + if (sve_data->min_vl == sve_data->max_vl) { + ksft_print_msg("Only one SVE VL supported, can't change\n"); + ksft_test_result_skip("change_sve_while_sme\n"); + return; + } + + /* Ensure we will trigger a change when we set the maximum */ + ret = prctl(sve_data->prctl_set, sve_data->min_vl); + if (ret != sve_data->min_vl) { + ksft_print_msg("Failed to set SVE VL %d: %d\n", + sve_data->min_vl, ret); + pass = false; + } + + /* Enable SM and ZA */ + smstart(); + + /* Trigger another VL change */ + ret = prctl(sve_data->prctl_set, sve_data->max_vl); + if (ret != sve_data->max_vl) { + ksft_print_msg("Failed to set SVE VL %d: %d\n", + sve_data->max_vl, ret); + pass = false; + } + + /* + * Spin for a bit with SM enabled to try to trigger another + * save/restore. We can't use syscalls without exiting + * streaming mode. + */ + for (i = 0; i < 100000000; i++) + smstart_sm(); + + /* + * TODO: Verify that ZA was preserved over the VL change and + * spin. + */ + + /* Clean up after ourselves */ + smstop(); + ret = prctl(sve_data->prctl_set, sve_data->default_vl); + if (ret != sve_data->default_vl) { + ksft_print_msg("Failed to restore SVE VL %d: %d\n", + sve_data->default_vl, ret); + pass = false; + } + + ksft_test_result(pass, "change_sve_with_za\n"); +} + +typedef void (*test_all_type)(void); + +static const struct { + const char *name; + test_all_type test; +} all_types_tests[] = { + { "change_sve_with_za", change_sve_with_za }, +}; + int main(void) { + bool all_supported = true; int i, j; ksft_print_header(); - ksft_set_plan(ARRAY_SIZE(tests) * ARRAY_SIZE(vec_data)); + ksft_set_plan(ARRAY_SIZE(tests) * ARRAY_SIZE(vec_data) + + ARRAY_SIZE(all_types_tests)); for (i = 0; i < ARRAY_SIZE(vec_data); i++) { struct vec_data *data = &vec_data[i]; unsigned long supported; supported = getauxval(data->hwcap_type) & data->hwcap; + if (!supported) + all_supported = false; for (j = 0; j < ARRAY_SIZE(tests); j++) { if (supported) @@ -666,5 +758,12 @@ int main(void) } } + for (i = 0; i < ARRAY_SIZE(all_types_tests); i++) { + if (all_supported) + all_types_tests[i].test(); + else + ksft_test_result_skip("%s\n", all_types_tests[i].name); + } + ksft_exit_pass(); } From patchwork Thu Jul 20 18:39:00 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 13320991 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 41B62EB64DD for ; Thu, 20 Jul 2023 18:39:52 +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:Cc:To:In-Reply-To:References:Message-Id :MIME-Version:Subject:Date:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kAY2qWsfnlDQd6cE9MhELMs5KJ1+D5zqiWPlmEARL3M=; b=jvHBUs0N0RUFii cqkNv8wDVenmxbm6xrpX5Y9qJchURZFCfDF9FskaAcW4BpdCgSj00BOxwdNyDjZVQn2PGm1dPbO49 1Qe1enrP4Ff9Ir5+bkbiTyX5gF+VZKCJJ/ewrwTiNrQ9rHQ4TkJClSl1L+s3a7dswM9Ga7xDALxXc kSFMsE4dFWEzgbNEV0intzliUDtCqjzR132iobsGLCVDtl2Fjafh4WoRz2E9hyVHv315NkdJFxi+y d0bkS4Sk8S1iAF4R3XfPQf7iBZeQjGByML+SMXvQJy3/ZUn/3k0q905JAV/88MLm22moH7OtH/BL/ 9EEB+rFJT46Dxh1Kallg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qMYYm-00Bv1S-1q; Thu, 20 Jul 2023 18:39:32 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qMYYY-00BuvN-0d for linux-arm-kernel@lists.infradead.org; Thu, 20 Jul 2023 18:39:19 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B42ED61BFA; Thu, 20 Jul 2023 18:39:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D507EC433C7; Thu, 20 Jul 2023 18:39:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689878357; bh=rXmOaMmqlk7QrELiC/kSDYYNiucDsBT8D5q7ohFdQ7s=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=mtgFWNoVWqppKfmmwXxHY8o8mfruxBcpLKPaSxviOeFSB2G6+jMlgOJ78/GJK3zyM YQivuehx4s4SjWWsN4xM6sAZEmyXkgNLlOCVKMv5/xVfMtIakGE6/QZZ2mrU4UynjF tKKo//JJKRRtRb7kfd4cL551+M2efF1R39kVXMKFbpLfzwSMUw/OP4XcFSU9W8/nNo vAOm8V2nd41dZcex48k+lsUx8u9tcNB+lr5v0KU8du4AY9lF1lJ4lK+1YMQIian7P4 6MW26EsuCRI0e8fp0Wt5lWv/DJp16stqfeaB6fGqRnqZHFrOpparJUO+S4O++RMeRR mQmFpyuK9SXcQ== From: Mark Brown Date: Thu, 20 Jul 2023 19:39:00 +0100 Subject: [PATCH v2 3/3] kselftest/arm64: Validate that changing one VL type does not affect another MIME-Version: 1.0 Message-Id: <20230720-arm64-fix-sve-sme-vl-change-v2-3-8eea06b82d57@kernel.org> References: <20230720-arm64-fix-sve-sme-vl-change-v2-0-8eea06b82d57@kernel.org> In-Reply-To: <20230720-arm64-fix-sve-sme-vl-change-v2-0-8eea06b82d57@kernel.org> To: Catalin Marinas , Will Deacon , Shuah Khan Cc: David Spickett , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Mark Brown X-Mailer: b4 0.13-dev-099c9 X-Developer-Signature: v=1; a=openpgp-sha256; l=1868; i=broonie@kernel.org; h=from:subject:message-id; bh=rXmOaMmqlk7QrELiC/kSDYYNiucDsBT8D5q7ohFdQ7s=; b=owGbwMvMwMWocq27KDak/QLjabUkhpSd9R4iIrrWIkXKwQIKwffTPk6wM8nqKk9d36291sEiQZGh RbuT0ZiFgZGLQVZMkWXts4xV6eESW+c/mv8KZhArE8gUBi5OAZjItzvs/wu9qy0kFdUf+G5IsXo2/7 hA/Zn8hGUznl1ZPTH9wTmOLVdtiw/kbM9N97+d5+DiXm8a6/TobS7388Be7ldpHnN0dyVNim351vDA WqKm+F/G2X3MsWyJxz9HX5zkW7pn0i03lxcy880MNniqfGGxDs7qibDhvLnvuv5tJVnG6sSsN05Tvq fJcabuT4uY0G9hfKT9xgSn74s2X/tdqdapw/J7eYjvi3vGwuY62bc1ZQVvepYWpLX32+zYvbr9KacP u8gNfevc8sqUee8MqoKOGG6Yaxr3xlZnayjTMyMdnqYVRdZH+jQbNXtN+BS4xPXm75nPVmG++OfPu4 KnZWZU9m3ZG8tzRNjlQ8wdDi4A 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-20230720_113918_320004_74C62A8B X-CRM114-Status: GOOD ( 16.51 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On a system with both SVE and SME when we change one of the VLs this should not result in a change in the other VL. Add a check that this is in fact the case to vec-syscfg. Signed-off-by: Mark Brown --- tools/testing/selftests/arm64/fp/vec-syscfg.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/arm64/fp/vec-syscfg.c b/tools/testing/selftests/arm64/fp/vec-syscfg.c index 58ea4bde5be7..5f648b97a06f 100644 --- a/tools/testing/selftests/arm64/fp/vec-syscfg.c +++ b/tools/testing/selftests/arm64/fp/vec-syscfg.c @@ -554,7 +554,8 @@ static void prctl_set_onexec(struct vec_data *data) /* For each VQ verify that setting via prctl() does the right thing */ static void prctl_set_all_vqs(struct vec_data *data) { - int ret, vq, vl, new_vl; + int ret, vq, vl, new_vl, i; + int orig_vls[ARRAY_SIZE(vec_data)]; int errors = 0; if (!data->min_vl || !data->max_vl) { @@ -563,6 +564,9 @@ static void prctl_set_all_vqs(struct vec_data *data) return; } + for (i = 0; i < ARRAY_SIZE(vec_data); i++) + orig_vls[i] = vec_data[i].rdvl(); + for (vq = SVE_VQ_MIN; vq <= SVE_VQ_MAX; vq++) { vl = sve_vl_from_vq(vq); @@ -585,6 +589,22 @@ static void prctl_set_all_vqs(struct vec_data *data) errors++; } + /* Did any other VLs change? */ + for (i = 0; i < ARRAY_SIZE(vec_data); i++) { + if (&vec_data[i] == data) + continue; + + if (!(getauxval(vec_data[i].hwcap_type) & vec_data[i].hwcap)) + continue; + + if (vec_data[i].rdvl() != orig_vls[i]) { + ksft_print_msg("%s VL changed from %d to %d\n", + vec_data[i].name, orig_vls[i], + vec_data[i].rdvl()); + errors++; + } + } + /* Was that the VL we asked for? */ if (new_vl == vl) continue;