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 C4554C6FD19 for ; Sun, 12 Mar 2023 15:39:08 +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:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=V7oL0Oa016O+m3USLEO+TWb6ZWFhcoe3MCRiV+6Dd7o=; b=xggPLqCJXsNj6m mMjFHsSfsgG7FQ1VcgA9meflZHZqToG5Oq3vuLWPrWo6rGCfDPzqGGzL4uTC1GwxNtwNETmgp5eaS i0sNfLok71pNVKT+Mxt6t+0u+8WvrxY+KPMAcTKI0F3W1eJPta0WbdAeb96m967U5vOAp7sLde8Rz KD/5utkQSDxOMqOIZgDrZyQCwdy7PdxXlyL6tul9XYZvnxkUKjaKrewib5KnUMexJzEPwmzlFhVb/ sgsQSFTApFv0Ssf13KpLNiiVvH+EAwNTjIJeJy9pMgomdOH8BAxQ3v/nfq8jE3u+enqSmqZdqxcu6 Az9w+TZeNqWbttA4TOpQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pbNld-002lq2-4o; Sun, 12 Mar 2023 15:37:49 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pbNlX-002lpd-Ve for linux-arm-kernel@lists.infradead.org; Sun, 12 Mar 2023 15:37:46 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 4BAC060F38; Sun, 12 Mar 2023 15:37:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7A7DC433EF; Sun, 12 Mar 2023 15:37:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678635461; bh=R1AumEUR0bc6e6nMbU15hmjqwiC8LvwLAyZqPz0mE0U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=W/0MwonhwuYJslF0MxV5sr6QvoeUmcoCR/F03L2q1FNbcozZDvTMWPOCerg6k1Sjx b2Fqd/TvWbEBvXCyVGfFGM2NWQXdSZ5E122LadxT+TTouRN2eBsZEVqJ+7kOsB97bJ ekO9KUdqnhgxpvqEBYc3ZdZuJOfNxroy9CqHds5/RNUfQZu6vhFd0vOCdVOCcz1Mjz hr9W4NBMFmMgEKzF3xqV5TNsRsnWCGgXtGaZE+RFZYLED7beFTvoS5bELjQaetjnog +/RgQWWhsISiRg6ZQYRGHv+jrnNYGy87z9obJEiTttGVA2iZ8wAvIlIALz9RU2JNCo ZbipuVX/Dcpcg== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pbNlT-00H1EO-BT; Sun, 12 Mar 2023 15:37:39 +0000 Date: Sun, 12 Mar 2023 15:37:39 +0000 Message-ID: <87v8j63rr0.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Paolo Bonzini , Shuah Khan , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: selftests: Add coverage of MTE system registers In-Reply-To: References: <20230308-kvm-arm64-test-mte-regs-v1-1-f92a377e486f@kernel.org> <87edpu5klk.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: broonie@kernel.org, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, pbonzini@redhat.com, shuah@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230312_083744_206142_267E05E3 X-CRM114-Status: GOOD ( 35.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 On Sun, 12 Mar 2023 14:35:13 +0000, Mark Brown wrote: > > On Sun, Mar 12, 2023 at 10:29:11AM +0000, Marc Zyngier wrote: > > Mark Brown wrote: > > > > static struct vcpu_config *vcpu_configs[] = { > > > &vregs_config, > > > @@ -1131,5 +1163,6 @@ static struct vcpu_config *vcpu_configs[] = { > > > &sve_pmu_config, > > > &pauth_config, > > > &pauth_pmu_config, > > > + &mte_config, > > > }; > > > static int vcpu_configs_n = ARRAY_SIZE(vcpu_configs); > > > Is there any reason why we sidestep the combinations of MTE with PAuth > > and PMU? I know this leads to an exponential set growth, but this is > > the very purpose of this test, and we found bugs related to this in > > the past. > > The test is already not bothering with the combinations of SVE > and pointer auth, it appeared that the intent of the test was > only to test specific combinations. From what's there it looks > more like there's something with PMU interacting specially with > things (it's all X and X+PMU) that needs coverage. I couldn't > see anything between it and MTE, though I nearly added a MTE+PMU > combination just for the sake of it. It's one of those areas > where it's hard to determine if there's an intent behind the > implementation choices made or if they're just whatever someone > happened to write and not particularly important or desired. It *is* desired. We've had cases of flags being reset at the wrong time and leading to issues that would be detected by this test. The PMU stuff is indeed one example, but similar things could happen between SVE+MTE, for example. > > > A good first step would be to be able to build these combinations > > dynamically, and only then add new sublists to the mix. > > That would certainly be a good idea, if we were heading in that > direction I'd also expect negative tests checking that for > example pointer authentication registers don't appear when that's > not enabled. I'm not sure that it's worth blocking all new > coverage for that though, there is still value in having a bit of > basic coverage even if not all the combinations are covered yet. Then where is the incentive to get it fixed? People will just keep piling stuff, and the coverage will increasingly become worse. We have to do it as some point, and now is as good a time as any. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel