From patchwork Thu Jul 13 20:06:04 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 13312608 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73350C001E0 for ; Thu, 13 Jul 2023 20:11:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231962AbjGMULs (ORCPT ); Thu, 13 Jul 2023 16:11:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230183AbjGMULq (ORCPT ); Thu, 13 Jul 2023 16:11:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9BFE330CA; Thu, 13 Jul 2023 13:11:16 -0700 (PDT) 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 8D81861B0F; Thu, 13 Jul 2023 20:11:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33903C433C9; Thu, 13 Jul 2023 20:10:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689279060; bh=o0ANSAw56sA/lMUOCihuB62S6J6BNaztJzZehhETvE0=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=ApDZj1uNZf71FBvouOCrf0wVUKZBSLI6OueVam0HtYW3CKzVHw7ccPspsR6GadW/t 6JKMYvbZIHWgHo+mC5GhpKoZnUrI4yHJ3rChkhiqrI9iAa1A85AO+40S/t0Nc0hw23 lbMkupHw15GIDRin0Ad11BWdAMmbEk+9E7FGUh+t4GaFXUpk4EMsxiVn40T8OEgrdk 4/YA+H/sXL/qhb8A4tY6dqOrfukCEm8vW587MmvQlmg9KeDPmMNnkEXjZ2j5BkwzCn UtqR6LgpSKUpJzDhElGqbr2t3hBPdN4LJ8Rct+OsKdkYdxJ+F8zBeGmaAQJvALZ075 J7TYA1T2d/psQ== From: Mark Brown Date: Thu, 13 Jul 2023 21:06:04 +0100 Subject: [PATCH 1/3] arm64/fpsimd: Ensure SME storage is allocated after SVE VL changes MIME-Version: 1.0 Message-Id: <20230713-arm64-fix-sve-sme-vl-change-v1-1-129dd8611413@kernel.org> References: <20230713-arm64-fix-sve-sme-vl-change-v1-0-129dd8611413@kernel.org> In-Reply-To: <20230713-arm64-fix-sve-sme-vl-change-v1-0-129dd8611413@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=3179; i=broonie@kernel.org; h=from:subject:message-id; bh=o0ANSAw56sA/lMUOCihuB62S6J6BNaztJzZehhETvE0=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBksFpNzlGIjJ25VfURcqNr5OdlZ9uZz5Sciz6zF2v/ AgnJnvOJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZLBaTQAKCRAk1otyXVSH0GjsB/ 0adS+55bGJsIYkt/TYHWkX71CLRv8+BFzENgFSc3PJTu/3/Z3R2CWVLT9snutH2r4EFffoYq1QdNvb QMUFXoBW1ih7dlCVaxTuZSifF0MNJ+U5Eq+AVO0xIIuKKChEsveQ8mAGCK9D/f+9nuOrnFnEHAkOrh OueZcuR/I8DNofEsSFRU4F7Vv/rEAUi5iYnbvPN32qo5z6CT0QMa1j+5vuMIBoeo47MYa7DnVoOp1A d2LSvG3K+LJ1qOaRCBVISQotHoM5zZS3aaZrqQxZ82+Cg8FiTO8BEek0TlBp+OcGJOBn6Qcclew/2T viSAjxBXH9Y7+48OYQTK8PKfKPh372 X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.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 if SME is active, 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 Reported-by: David Spickett Signed-off-by: Mark Brown --- arch/arm64/kernel/fpsimd.c | 32 +++++++++++++++++++++++++------- 1 file changed, 25 insertions(+), 7 deletions(-) diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 7a1aeb95d7c3..a527b95c06e7 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -847,6 +847,9 @@ 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; + bool alloc_sve = true; + if (flags & ~(unsigned long)(PR_SVE_VL_INHERIT | PR_SVE_SET_VL_ONEXEC)) return -EINVAL; @@ -897,22 +900,37 @@ 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; + } else { + alloc_sve = 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, they will + * be reallocated to the correct size on next use. If we need + * SVE state due to having untouched SME state then reallocate + * it immediately. */ sve_free(task); - if (system_supports_sme() && type == ARM64_VEC_SME) + if (free_sme) sme_free(task); + if (alloc_sve) + sve_alloc(task, true); task_set_vl(task, type, vl); From patchwork Thu Jul 13 20:06:05 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 13312609 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 443C5C00528 for ; Thu, 13 Jul 2023 20:11:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233778AbjGMULr (ORCPT ); Thu, 13 Jul 2023 16:11:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232197AbjGMULq (ORCPT ); Thu, 13 Jul 2023 16:11:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7C7D30CB; Thu, 13 Jul 2023 13:11:16 -0700 (PDT) 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 93DB261B50; Thu, 13 Jul 2023 20:11:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69A12C433C8; Thu, 13 Jul 2023 20:11:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689279062; bh=pefhisUmRsg+2EzyXrIeOHRp6qKwWRumC3ginNtyGbg=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=IFrTAcPEgpsvm3EHMhXwpsqfxTmSpuqajNYjOslXWK4dh+jbHplsmrSs8Fb6BnPRu CP/eYAUyWRjG/clgJo6KawD8+bHtKBSRatScz+MU+zn3ba3eLIBx5ELADNKxZHETYT B612okPlZ36n26mv4SEQOe4elNK6vE4BfNQYE2Xiaic2aAu1VhqnHx35YmEbxICcmM k3sIx6dj2lYhkdfd6QfaBIjC3lsour570ZCzl2vaaPAaplL0J24rN448pwWcrwnHmR ZxD15ZG2avOCNBMStj97lD96phzejTBFWlG6jrKLissj6rA5wnKVR8U8artAcYi5/L Lcocnrmnll3Nw== From: Mark Brown Date: Thu, 13 Jul 2023 21:06:05 +0100 Subject: [PATCH 2/3] kselftest/arm64: Add a test case for SVE VL changes with SME active MIME-Version: 1.0 Message-Id: <20230713-arm64-fix-sve-sme-vl-change-v1-2-129dd8611413@kernel.org> References: <20230713-arm64-fix-sve-sme-vl-change-v1-0-129dd8611413@kernel.org> In-Reply-To: <20230713-arm64-fix-sve-sme-vl-change-v1-0-129dd8611413@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/pANAwAKASTWi3JdVIfQAcsmYgBksFpOcK0+T8pCWAuXL/8zAm0/WFELWdgLFEWfAMyI 3YX08uSJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZLBaTgAKCRAk1otyXVSH0Hi+B/ 9h4U7cnGc47k8jKeNn8cCML9cHNXsPXGEqUE1GNoIL2sW8X20OnE36eQbPm2qXE5xpYeQ1biIhue9g gZq7RiqwAyz4jO6vHRhjEjLLBDJkfPdNeWw0n4Ay+V4BmGAPwN8Wxwgy8NuLtis5spMxgqrZ4JaKEo pxgo5E/xFGMGc4yHoF2zCSFfibZTnfGVRp055aPQSR+vT6l7nP/riYdEBvhVreROazVrYncHmcJyTI +9GbgrNFratJ7XMUKwQrAZ1JiPtEQBJlTkVlHGCdtFMDhlTD0h2T+9J3oqopAAyHfoxNLV9lHDbGML 5daepMDk/Di9fa3vXuOOBgrXXunnvA X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.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 13 20:06:06 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 13312610 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82F53C001DC for ; Thu, 13 Jul 2023 20:11:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230309AbjGMULt (ORCPT ); Thu, 13 Jul 2023 16:11:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233758AbjGMULr (ORCPT ); Thu, 13 Jul 2023 16:11:47 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5065730D1; Thu, 13 Jul 2023 13:11:17 -0700 (PDT) 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 9DC9561B5C; Thu, 13 Jul 2023 20:11:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7448DC433C7; Thu, 13 Jul 2023 20:11:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689279064; bh=rXmOaMmqlk7QrELiC/kSDYYNiucDsBT8D5q7ohFdQ7s=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=Dh3Hji+GokfBj3Nw3od6f/WvxyQj4FgLI9SYKpUbWImvCfhuEpnx9l9bEXQ0oNCQ2 +fW2QhhsEb86pKNxOLTNFV1bbkVD18YpvgGlBCYgzVPyWtwax7OmkBVMLwd1wWyH4K +EA48T3/KHxguLpRWhzipdPLj0PW5qU7njdpOMbBHjkSHi14dR6ibThQiNWRxsCFxw bNaCielNdvqJNpicq+8DFVZotQ3UCQPG4q3dF0j17+gjlKGQ0ZEZ+uSjMGS3nJ88xw hdOjQhQPvOCUo7v+CFAw9AC2kDknpiXMNEgN9poccUumVaAz/I7KDzLt0wIWwQKse7 CzmaLtIJ72d4A== From: Mark Brown Date: Thu, 13 Jul 2023 21:06:06 +0100 Subject: [PATCH 3/3] kselftest/arm64: Validate that changing one VL type does not affect another MIME-Version: 1.0 Message-Id: <20230713-arm64-fix-sve-sme-vl-change-v1-3-129dd8611413@kernel.org> References: <20230713-arm64-fix-sve-sme-vl-change-v1-0-129dd8611413@kernel.org> In-Reply-To: <20230713-arm64-fix-sve-sme-vl-change-v1-0-129dd8611413@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=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBksFpOCjYO1OOQVtYTH9sPPOR3+Xz9V8BWbDTBW4Pp GWfNe4SJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZLBaTgAKCRAk1otyXVSH0Iu2B/ wIRfaFgefheO/Xj5GZBgB9FVb81SFw5aD50REv/xVXdJ5spcz4DGwzM+o29bB6UEo6q9/K/zeAZ5m3 RkXHaCr7e5oOCNQ2yA7nmaUxgkVRurq7ZR0iw7a+CXa2v+kJJXm57gxwzW2TxXuifYmhRH4I7v6TQs +xstxbf7hyvX70BnVYgj6LFdswICVgXIBngyV9141gpgkApw8se8jObvU8LD0bwaOIwVxXj2YMrLn3 pp6DZMMUv+xgE3WvbPXmf5VdLoIvPzNE8UARWTL0duYKSBIF3DNTIcEqS1dAxfU9RMPatmAvTKqGbr VtpN0VmWvVGBW2yYZz+ID2/hu1Q4i+ X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.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;