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 B6462C7EE24 for ; Tue, 6 Jun 2023 16:43:01 +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=2NkfAUJxUeKnduYygNj9CRyL112IRl1crgYfH4D+HnY=; b=fokZlvIBMyPt61 UXuTEgRxg9P9GgXmyG7lVig3ThPh+iOi2TIBYqYqtkQjsgsoJuzl5DZxjA66kLhmRnjdazB/QoFJb LynYAf7CWNHVLp44cMC0PhhT1hla3vPiU85bGvLuPj/Sviuel3EO26cIGfwbR19BznJEeCXLPYnxe /SVKHqewSjSodswztZXS5lyxOJL3BVfmZVbMaSuHdiILwVklwOls1Sh21yDWdBl7H+FteXrU2Ad9o t/vLmWFYBdtCK8M/QnVomxLWnslz2N79TYk7EIMbTQcqBbpdJ7PJWpqmWQOP5ENqXbsnlLgMhO6si HEJXuhMaWAO+0vaKrYPA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q6ZlP-002TUi-02; Tue, 06 Jun 2023 16:42:31 +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 1q6ZlM-002TUB-2j for linux-arm-kernel@lists.infradead.org; Tue, 06 Jun 2023 16:42:30 +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 6A7AE6303E; Tue, 6 Jun 2023 16:42:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32489C433EF; Tue, 6 Jun 2023 16:42:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686069748; bh=paBNFQu5syHarCHqUVVsk0aOnH3b4HZY2eEojj0JhFw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sq9/IfqLWTnCNGzQ2zr9sKOg+3CeFm2iKhenKP+YsQThZjlBX2PCUJNZQg5vPyy5j nuxLudvUDhbg80RAH1c+4ZROKW4KucajeqQf6hH3LA2HNSyjbbueMO+7Hl1f2Cu+7C dSh5BevPQw3k0BQYiv6xwISXDKZ9u3a1+pM7Di8VHbEtvx+N+h2othHYJVFDC2Fctc LzrfTo2sCcYF97E8BCqrhmxsc9UgTbc/4qh2Fp0kDUgKkZZCnanW4bLOWqDal2E2tR A2C+OvJm5f/kr0wqXjoi1YPY1Z2gd31CEE2QfW5AXNQ2leauhBqcsenMruSxroM4XN 8g+iiPR77KduQ== Received: from 152.5.30.93.rev.sfr.net ([93.30.5.152] 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 1q6ZlJ-003GTy-RE; Tue, 06 Jun 2023 17:42:26 +0100 Date: Tue, 06 Jun 2023 17:42:24 +0100 Message-ID: <87legwo83z.wl-maz@kernel.org> From: Marc Zyngier To: Cornelia Huck Cc: 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 In-Reply-To: <87h6rl50dl.fsf@redhat.com> 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> 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/28.2 (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: 93.30.5.152 X-SA-Exim-Rcpt-To: cohuck@redhat.com, surajjs@amazon.com, 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 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-20230606_094228_965130_E26CDD18 X-CRM114-Status: GOOD ( 33.72 ) 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 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! > > > Why are you > > actively crippling the MTE version presented to the guest, and > > potentially introduce unexpected behaviours? > > While the code does not look correct here, I think we'll need some way to > control which version of MTE is presented to the guest for compatibility > handling; does it make sense to control this per-cpu, or does it need to > be a vm-wide setting? It absolutely needs to be VM-wide. Only having half the vcpus supporting tags wouldn't make much sense. But the problem is that the various versions of MTE are not necessarily compatible, as MTE4 makes MTE3 optional (with a fallback to MTE2)... There are more subtleties around the what instructions are available in which mode, and whether the various subfeatures can be configured or not. Thanks, 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