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 E55DEC7EE23 for ; Thu, 8 Jun 2023 17:57:39 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=d0MNo9SPlyrhrt98uvVuhaCjNl5e7fEiY0DBWr413xY=; b=Ff3yoUEvGbTlGs /zNilfGTRQCTRUJoU1UN9w89utNGY11Vqs1bk4Oiy89y3A5InR4WN2LXUSQZwZKEjFPx30nzSix+T 2Rj1iBWdMyBJs3S9fWg1vOKPLY5IeXNcU0VdOCs6bJLHoJfW9PVpEXxWlmYPl86OqOUzhYG08HM49 37mYzRXNNH5u1UTQGzmC7tid0WJTQ4WhnVvOJSyCX5jK5sy3JAXCz2ltXT2dG+y3K8bWq8kFKgcIb CYg+X4xhoINlcB5zL6RSx3yNTsa1jmAgP7sitaHUY+a/SpsLmw+p9d2T0VnOPHRgSx8cVLGNhaCYp 20zWS4KUdcH1Qlp0ZJBQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q7Jsq-00A6Ms-1N; Thu, 08 Jun 2023 17:57:16 +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 1q7Jsn-00A6MI-2O for linux-arm-kernel@lists.infradead.org; Thu, 08 Jun 2023 17:57:15 +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 4395064FFD; Thu, 8 Jun 2023 17:57:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D14ACC433D2; Thu, 8 Jun 2023 17:57:09 +0000 (UTC) Date: Thu, 8 Jun 2023 18:57:07 +0100 From: Catalin Marinas To: Marc Zyngier Cc: Cornelia Huck , Suraj Jitindar Singh , jingzhangos@google.com, alexandru.elisei@arm.com, james.morse@arm.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oupton@google.com, pbonzini@redhat.com, rananta@google.com, reijiw@google.com, suzuki.poulose@arm.com, tabba@google.com, will@kernel.org, sjitindarsingh@gmail.com Subject: Re: [PATCH 3/3] KVM: arm64: Use per guest ID register for ID_AA64PFR1_EL1.MTE Message-ID: References: <20230602005118.2899664-1-jingzhangos@google.com> <20230602221447.1809849-1-surajjs@amazon.com> <20230602221447.1809849-4-surajjs@amazon.com> <873539ospa.wl-maz@kernel.org> <87h6rl50dl.fsf@redhat.com> <87legwo83z.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87legwo83z.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230608_105713_857937_2597E6B8 X-CRM114-Status: GOOD ( 29.75 ) 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 Tue, Jun 06, 2023 at 05:42:24PM +0100, Marc Zyngier wrote: > On Mon, 05 Jun 2023 17:39:50 +0100, > Cornelia Huck wrote: > > On Sat, Jun 03 2023, Marc Zyngier wrote: > > > On Fri, 02 Jun 2023 23:14:47 +0100, > > > Suraj Jitindar Singh wrote: > > >> > > >> With per guest ID registers, MTE settings from userspace can be stored in > > >> its corresponding ID register. > > >> > > >> No functional change intended. > > >> > > >> Signed-off-by: Suraj Jitindar Singh > > >> --- > > >> arch/arm64/include/asm/kvm_host.h | 21 ++++++++++----------- > > >> arch/arm64/kvm/arm.c | 11 ++++++++++- > > >> arch/arm64/kvm/sys_regs.c | 5 +++++ > > >> 3 files changed, 25 insertions(+), 12 deletions(-) > > >> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > > >> index ca18c09ccf82..6fc4190559d1 100644 > > >> --- a/arch/arm64/kvm/arm.c > > >> +++ b/arch/arm64/kvm/arm.c > > >> @@ -80,8 +80,17 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, > > >> if (!system_supports_mte() || kvm->created_vcpus) { > > >> r = -EINVAL; > > >> } else { > > >> + u64 val; > > >> + > > >> + /* Protects the idregs against modification */ > > >> + mutex_lock(&kvm->arch.config_lock); > > >> + > > >> + val = IDREG(kvm, SYS_ID_AA64PFR1_EL1); > > >> + val |= FIELD_PREP(ID_AA64PFR1_EL1_MTE_MASK, 1); > > > > > > The architecture specifies 3 versions of MTE in the published ARM ARM, > > > with a 4th coming up as part of the 2022 extensions. > > > > Is that the one that adds some more MTE bits in AA64PFR1 and > > AA64PFR2? > > Yeah, that. You get ID_AA64PFR1_EL1.{MTE,MTE_frac,MTEX}, plus > ID_AA64PFR2_EL1.{MTEFAR,MTESTOREONLY,MTEPERM}... It this sounds like a > train wreck, then it probably is one! I stared about an hour at that documentation and I think I got it (well, for the next couple of hours). The disappearing of MTE_FEAT_ASYNC from MTE2 is potentially problematic but the worst that can happen is that async faults are simply not triggered (and TBH, those "faults" were not that useful anyway). MTE4 without ASYM is defined in a weird way. Basically there's no such thing as MTE4, just 2 and 3 (the latter bringing in ASYM) with some extra features like store-only, stage 2 permission, canonical tag checking. I don't think any of these new MTE extensions add any state that KVM should care context-switch, so we should be fine. Does KVM limit the maximum value of the ID field exposed to user? Some future MTE9 may add new state, so better to be safe (I thought we handled these cases but can't find it now). It's also probably safe to disable MTE altogether if there's any difference between all these fields on different CPUs (I don't think we currently do, we just go for lower safe while ignoring MTE_frac, MTEX). Regarding MTEX, I don't think Linux would ever make use of the canonical tag checking. The enabling bit is unfortunately in TCR_EL1 which we don't context-switch (and maybe cached in the TLB, I haven't checked the latest spec). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel