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 98F45C369D1 for ; Sun, 27 Apr 2025 17:26:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=z1hhjBMZbaZUtb5QiEgVKXUmU5EQs2VJPNlNhpg1JAc=; b=Udcbj93zW91EyHoJsY1qRPDvwP 3sLNkKZml/C9zLtR8to1GbOpqSVQlQ1TItYJxn3OevNZ+z7Mq1d7OhLJukW6QZvgqTpa9PykWehWO +hoX/b0wUPhRVM3j6ZoAotn3sU8eJADdUyGdQGYECY6Ied8FL16FGuknSaq1ikQxQ0g0/jyN1m2jW CQC1XWmGyl8vSdeTwS8sr2YVUUHEo89+FMZBku546IW0g6WBakD1HAk64HDeyN3nUtx42pOXIriQ4 NETPRET9+JI49dQSHzY2+GDVntdGtJ1qejWbFbmt2uxPkTaOTt2f0ACFL5jUaj4dZiY92dLhRw5W6 oRQ/FNzw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1u95lh-00000003pN0-3iCp; Sun, 27 Apr 2025 17:26:17 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1u95jk-00000003pHS-3WCd for linux-arm-kernel@lists.infradead.org; Sun, 27 Apr 2025 17:24:18 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 39D9B5C4922; Sun, 27 Apr 2025 17:21:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9DE67C4CEE3; Sun, 27 Apr 2025 17:24:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745774653; bh=zlvI/OsYZS9TORbwigHYcZcf8vMrlAxBIJ912DxqI+s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=U7i3EM+93tP91zykMn38I1S5J7RHxE9UAZKjLXNt0GKMtIeBPVqPoUS8NXLhRP+0c dUsZy32Re3q8yTJT2ilO+nWtEaPcmbWplPelWY9zToczEYe6SzBQrIRzyWRViywIVE dExFK5kg+qJYFeRlT4USTGViT/OnZLxcDCDSVXzXLeyPiPjzLlt8UXHv5SZnBA1YUx TbBLTdxTFKhb8kJuatMKobRdnwy2Rsir5+kh2P1BZwCVNqqRvwuah+b76aA7vHTyJy 04JRKeIHNC3Lr76RDEc4NTccAMlPAQnug4wty70mBHv6NizQkCXDfGyqowqJsd1sS3 MOIxgxxileqxw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1u95jf-009JnY-Df; Sun, 27 Apr 2025 18:24:11 +0100 Date: Sun, 27 Apr 2025 18:24:10 +0100 Message-ID: <86bjshjz5x.wl-maz@kernel.org> From: Marc Zyngier To: Ben Horgan Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, shuah@kernel.org Subject: Re: [RFC PATCH 2/3] KVM: arm64: Make MTE_frac masking conditional on MTE capability In-Reply-To: <20250414124059.1938303-3-ben.horgan@arm.com> References: <20250414124059.1938303-1-ben.horgan@arm.com> <20250414124059.1938303-3-ben.horgan@arm.com> 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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ben.horgan@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, shuah@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-20250427_102416_964271_7383570E X-CRM114-Status: GOOD ( 33.65 ) 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 Mon, 14 Apr 2025 13:40:58 +0100, Ben Horgan wrote: > > If MTE_frac is masked out unconditionally then the guest will always > see ID_AA64PFR1_EL1_MTE_frac as 0. However, a value of 0 when > ID_AA64PFR1_EL1_MTE is 2 indicates that MTE_ASYNC is supported. Hence, for > a host with ID_AA64PFR1_EL1_MTE==2 and ID_AA64PFR1_EL1_MTE_frac==0xf > (MTE_ASYNC unsupported) the guest would see MTE_ASYNC advertised as > supported whilst the host does not support it. Hence, expose the sanitised > value of MTE_frac to the guest and user-space. > > As MTE_frac was previously hidden, always 0, and KVM must accept values > from KVM provided by user-space, when ID_AA64PFR1_EL1.MTE is 2 allow > user-space to set ID_AA64PFR1_EL1.MTE_frac to 0. However, ignore it to > avoid incorrectly claiming hardware support for MTE_ASYNC in the guest. > > Note that linux does not check the value of ID_AA64PFR1_EL1_MTE_frac and > wrongly assumes that MTE async faults can be generated even on hardware > that does nto support them. This issue is not addressed here. > > Signed-off-by: Ben Horgan > --- > arch/arm64/kvm/sys_regs.c | 26 ++++++++++++++++++++++++-- > 1 file changed, 24 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 005ad28f7306..9ae647082684 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1600,13 +1600,14 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu, > val = sanitise_id_aa64pfr0_el1(vcpu, val); > break; > case SYS_ID_AA64PFR1_EL1: > - if (!kvm_has_mte(vcpu->kvm)) > + if (!kvm_has_mte(vcpu->kvm)) { > val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE); > + val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE_frac); > + } > > val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_SME); > val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_RNDR_trap); > val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_NMI); > - val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE_frac); > val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_GCS); > val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_THE); > val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTEX); > @@ -1953,11 +1954,32 @@ static int set_id_aa64pfr1_el1(struct kvm_vcpu *vcpu, > { > u64 hw_val = read_sanitised_ftr_reg(SYS_ID_AA64PFR1_EL1); > u64 mpam_mask = ID_AA64PFR1_EL1_MPAM_frac_MASK; > + u8 mte = SYS_FIELD_GET(ID_AA64PFR1_EL1, MTE, hw_val); > + u8 user_mte_frac = SYS_FIELD_GET(ID_AA64PFR1_EL1, MTE_frac, user_val); > > /* See set_id_aa64pfr0_el1 for comment about MPAM */ > if ((hw_val & mpam_mask) == (user_val & mpam_mask)) > user_val &= ~ID_AA64PFR1_EL1_MPAM_frac_MASK; > > + /* > + * Previously MTE_frac was hidden from guest. However, if the > + * hardware supports MTE2 but not MTE_ASYM_FAULT then a value > + * of 0 for this field indicates that the hardware supports > + * MTE_ASYNC. Whereas, 0xf indicates MTE_ASYNC is not supported. > + * > + * As KVM must accept values from KVM provided by user-space, > + * when ID_AA64PFR1_EL1.MTE is 2 allow user-space to set > + * ID_AA64PFR1_EL1.MTE_frac to 0. However, ignore it to avoid > + * incorrectly claiming hardware support for MTE_ASYNC in the > + * guest. > + */ > + > + if (mte == ID_AA64PFR1_EL1_MTE_MTE2 && The spec says that MTE_frac is valid if ID_AA64PFR1_EL1.MTE >= 0b0010. Not strictly equal to 0b0010 (which represents MTE2). Crucially, MTE3 should receive the same treatment. > + user_mte_frac == ID_AA64PFR1_EL1_MTE_frac_ASYNC) { > + user_val &= ~ID_AA64PFR1_EL1_MTE_frac_MASK; > + user_val |= hw_val & ID_AA64PFR1_EL1_MTE_frac_MASK; This means you are unconditionally propagating what the HW supports, which feels dodgy, specially considering that we don't know how MTE_frac is going to evolve in the future. I think you should limit the fix to the exact case we're mitigating here, not blindly overwrite the guest's view with the HW's capability. Thanks, M. -- Without deviation from the norm, progress is not possible.