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 63B31C79F9E for ; Mon, 7 Sep 2026 12:13:59 +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=NecDGqlvwJfi+txz+jbfiLJQsG0Fh5Rj2eIZtOMxuME=; b=mYgkCtu6opWJbXQNRSL5yAnHqN WucovaL1CqBLid2YIaiI2uD8/b0A6/u4Vaci41yfms2wOHvzUNjrOx5yRcFsb5z4oVkY7FO09237I 5kCaLTm7nARoCE5BpzKJ+wTx02+UcZ6wxEzdi/3J0zjFDGG6V/7+4h0bGTCwIZ1gCWOSeoBS5PyFa JojrF5g8dJ0U8WNyvY64oMJNslnbm3q5kFivj6DnQKTHTNeMXrAwwqF+9vqJk5XFZnXtASYu3ETIe VaDDuV7s3d2/cEedMCUYzeyLvI4ItgjaQWiuIQMwHfDw/pBgkUT8LIGgVk/n6fzDYxC5TGkGuggW2 9fvFu+Ug==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x3YEN-00000006lpX-2mOL; Mon, 07 Sep 2026 12:13:47 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x3YEK-00000006lpF-00GX for linux-arm-kernel@lists.infradead.org; Mon, 07 Sep 2026 12:13:44 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 27AFB601F9; Mon, 7 Sep 2026 12:13:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D06FD1F00A3A; Mon, 7 Sep 2026 12:13:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788783222; bh=NecDGqlvwJfi+txz+jbfiLJQsG0Fh5Rj2eIZtOMxuME=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=IIBugRBA+PkC18oj9xBLFEzHli+iSNVYmSt7tIk1kQ1+XsUR6GiZ6dINOKxPmH8jR jRvmNqEEvz2nDcID7OimfgpAFd722XO4m7mymmTq35MP3LTel0gd/mU3c4/rNqge4x +M+gdtUn3t5FYykZZnJyvXYcb4OpnjSLblVv9ymySRe5BG5kWL5rWQD5Aq1HwPSxqA MJGm5mqIktY3l4/7o9OaIjGbeRg0+k4TQtaEjbt8LsVbT8Gk31bzirSnZan/v5n5EB AwVBb4EQnTOizOQnSq3hMhcNFTeB6xBn+K5ZCv/IqwYRvV3/7+Jlqm7SWXiRX0cU+o FpTdspeyt7XcQ== 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.98.2) (envelope-from ) id 1x3YEF-00000005kyX-1fLo; Mon, 07 Sep 2026 12:13:40 +0000 Date: Mon, 07 Sep 2026 13:13:38 +0100 Message-ID: <86cxup45u5.wl-maz@kernel.org> From: Marc Zyngier To: Suzuki K Poulose Cc: Kohei Enju , Steven Price , kvm@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , Will Deacon , James Morse , Oliver Upton , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun , "Aneesh Kumar K . V" , Emi Kisanuki , Vishal Annapurve , WeiLin.Chang@arm.com, Lorenzo Pieralisi Subject: Re: [PATCH v16 22/45] KVM: arm64: CCA: Handle RMI_EXIT_RIPAS_CHANGE In-Reply-To: <30b4137b-1445-49c0-bd1c-98dbac5d70f6@arm.com> References: <20260803134403.80630-1-steven.price@arm.com> <20260803134403.80630-23-steven.price@arm.com> <86fqzl4biu.wl-maz@kernel.org> <30b4137b-1445-49c0-bd1c-98dbac5d70f6@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/30.1 (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: suzuki.poulose@arm.com, enju.kohei@fujitsu.com, steven.price@arm.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, james.morse@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, joey.gouly@arm.com, alexandru.elisei@arm.com, christoffer.dall@arm.com, tabba@google.com, linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com, gshan@redhat.com, sdonthineni@nvidia.com, alpergun@google.com, aneesh.kumar@kernel.org, fj0570is@fujitsu.com, vannapurve@google.com, WeiLin.Chang@arm.com, lpieralisi@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-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, 07 Sep 2026 12:58:22 +0100, Suzuki K Poulose wrote: > > On 07/09/2026 11:10, Marc Zyngier wrote: > > On Mon, 07 Sep 2026 06:05:29 +0100, > > Kohei Enju wrote: > > > > [...] > > > >> Although the root cause is an RMM bug, should we also guard RIPAS_SET > >> against this no-progress case? > > > > No. We really should *prevent* the kernel from using a known broken > > RMM. Which brings me to one of my long standing request: how to we > > enforce the minimum version of RMM that KVM is willing to work with? > > (1) Do you mean the RMM ABI version ? > (2) Or the particular build version of a given RMM firmware > implementation ? > > As far as (1) is considered, the kernel already sticks to a single > version, v2.0 and doesn't support anything else. And we are fine with > KVM/Linux supporting a single version of RMM and deprecating the > support for older RMM versions as we decide to move on. > > As for (2), the RMM ABI doesn't provide any information about the > build/fix version for a given implementation. I will raise this > within Arm. But it appears that only checking for RMM v2.0 wouldn't be sufficient in the case that Kohei faces. Nothing distinguishes a vanilla RMM from a fixed one, as we can only check for the ABI. We need a way to identify *implementations* so that we can refuse to use one that is known to be broken. And given that each and every vendor already have their own toy RMM, each with their own "added value", it cannot be a simple "build number" identifier. This is not the first time I ask for this. Thanks, M. -- Without deviation from the norm, progress is not possible.