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 241FEC87FCA for ; Thu, 31 Jul 2025 07:59:48 +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=rKm2s087Ls9z5lcvlGv8fjL0CmWav1HkuCIzcbNnRfg=; b=KlwrKRNdqRtn8YgXCbGL03AZyQ Wpn4LX0s/JvPmEOOHdij5TeBdC2xEloQ5r8azyFg9wArvCiwSkfSthL5dFlBlCTq3R3IYMhILi5W6 trPjMGObvOF2e4NxvmbWcP+uwVRGxDecOyhmiOAJFqesa759OPDBg68qVLniIr9SjCC/oVLcwjJLs GCBhhCuKW7pbuT9ZdVmglqirPNPUbdZBCJ08vAvr+GDizphnZH9LWkFZB9P6UvYyZeNnEM84KZD1Z MJ7TJstc1jd7WL119SLEaL6QYitiQz8q6FVufhSqcP7Z86NPBeQrPiKW/OEvISl5wxwE/N7Irs/jD 7LeOve1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uhOCS-000000036W0-1cXM; Thu, 31 Jul 2025 07:59:40 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uhO9v-000000035wC-1l1Z for linux-arm-kernel@lists.infradead.org; Thu, 31 Jul 2025 07:57:04 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C20505C5D20; Thu, 31 Jul 2025 07:57:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6C042C4CEEF; Thu, 31 Jul 2025 07:57:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753948622; bh=61dcSPYpfvv/XWFpt2pjSx2eN1l00uIV5kw223T8ITM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=UkGAA0yj/3k/okEA7kxXkDaNLmJ5M9UWEjRsfbaWOr7vtLQUNzzMu0Eu/B7+fnIo/ KLjrBa1BRvI2W56uH8/STvBEi+/IASgDPRKiAVKiIaW7sakZyL80biAxOpCTn4CYYU O3C6L8IIpbmsKLoJvcJqdXevXEMCwy5PLgxPU5wiK6PkUAdtt85m0mALeHO+TCrki4 RM0bZmtpqMVj7LMFnBcdN4Wv2qaP4hhQ8JosZnkOnLiThkOUTkV2uHSat0trox9HTo GMlCHV4PkolOUr1n4kJJAnveLs+ks5EWH+5tlHPTELoQNRuXoL18UI/FIv4jVohmGt oEFmuJcfXLTUQ== 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 1uhO9r-002qnd-VE; Thu, 31 Jul 2025 08:57:00 +0100 Date: Thu, 31 Jul 2025 08:56:59 +0100 Message-ID: <86zfck7pys.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: perlarsen@google.com, Oliver Upton , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Sudeep Holla , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, ahomescu@google.com, armellel@google.com, arve@android.com, ayrton@google.com, qperret@google.com, sebastianene@google.com, qwandor@google.com Subject: Re: [PATCH v7 4/5] KVM: arm64: Bump the supported version of FF-A to 1.2 In-Reply-To: References: <20250701-virtio-msg-ffa-v7-0-995afc3d385e@google.com> <20250701-virtio-msg-ffa-v7-4-995afc3d385e@google.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: will@kernel.org, perlarsen@google.com, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, ahomescu@google.com, armellel@google.com, arve@android.com, ayrton@google.com, qperret@google.com, sebastianene@google.com, qwandor@google.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-20250731_005703_539847_B5397097 X-CRM114-Status: GOOD ( 26.06 ) 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 Fri, 18 Jul 2025 14:45:17 +0100, Will Deacon wrote: > > On Tue, Jul 01, 2025 at 10:06:37PM +0000, Per Larsen via B4 Relay wrote: > > From: Per Larsen > > > > FF-A version 1.2 introduces the DIRECT_REQ2 ABI. Bump the FF-A version > > preferred by the hypervisor as a precursor to implementing the 1.2-only > > FFA_MSG_SEND_DIRECT_REQ2 and FFA_MSG_SEND_RESP2 messaging interfaces. > > > > We must also use SMCCC 1.2 for 64-bit SMCs if hypervisor negotiated FF-A > > 1.2, so ffa_set_retval is updated and a new function to call 64-bit smcs > > using SMCCC 1.2 with fallback to SMCCC 1.1 is introduced. > > > > Update ffa_call_supported to mark FF-A 1.2 interfaces as unsupported > > lest they get forwarded. > > > > Co-developed-by: Ayrton Munoz > > Signed-off-by: Ayrton Munoz > > Signed-off-by: Per Larsen > > --- > > arch/arm64/kvm/hyp/nvhe/ffa.c | 18 ++++++++++++++---- > > include/linux/arm_ffa.h | 1 + > > 2 files changed, 15 insertions(+), 4 deletions(-) > [..] Late catching up on this, as we seem to get a version a day, probably in the hope that it will keep *something* away,... > > @@ -734,7 +741,10 @@ static int hyp_ffa_post_init(void) > > if (res.a0 != FFA_SUCCESS) > > return -EOPNOTSUPP; > > > > - switch (res.a2) { > > + if ((res.a2 & GENMASK(15, 2)) != 0 || res.a3 != 0) > > + return -EINVAL; > > Why are you checking bits a2[15:2] and a3? The spec says they MBZ, > so we shouldn't care about enforcing that. In fact, adding the check > probably means we'll fail if those bits get allocated in future. I have the exact opposite approach. If we don't check that they are 0 for v1.2 and previous versions, we won't be able to tell what they mean when they are finally allocated to mean something in version 1.337. Until we support such version, MBZ should be enforced, because we otherwise don't understand what the "client" is trying to say. And we don't understand, we're guaranteed to do the wrong thing. Thanks, M. -- Without deviation from the norm, progress is not possible.