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 3DCBDCD128A for ; Thu, 11 Apr 2024 09:05:45 +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=M3zqlvlYByqe4RMAAKM+JmwxiZC2HrJ4qv+r5PyV4hg=; b=FhZsm3fN7lAyWX 0/m9n7ZD8XLpSGE8fdTqBL2wkzehV40E9rInaBsYLn5RBVqAeNjcexEJB5m7g9tpQo5nqQGF4KOdX k35t47WRH+WOkDKfX4IWWmwGwMuMJ4mCTecLmtMu0ZROVnPvwLsAJPxFtdEyVkpLIC8IARjszWqCn bhydnJnNeIXKpf2aTddpzSgYD0UBSgkNzZ47+txzNW2l/vskcujXM1YeHW3dlwWJMo1UkEixKIWaa v9CqVZVJ00TjU1rEO+lti5owx9qZKH1qoG9KQkPct40gNlWgAOVFme7MsLJS1vjkBZ9ln5UmkvKRU vGDo1fAJo/+fhPgIp4lA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ruqN6-0000000BEao-0m3S; Thu, 11 Apr 2024 09:05:28 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ruqN2-0000000BEZQ-2C8m for linux-arm-kernel@lists.infradead.org; Thu, 11 Apr 2024 09:05:26 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D8DC7113E; Thu, 11 Apr 2024 02:05:51 -0700 (PDT) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 01D263F6C4; Thu, 11 Apr 2024 02:05:19 -0700 (PDT) Date: Thu, 11 Apr 2024 10:05:17 +0100 From: Sudeep Holla To: Lorenzo Pieralisi Cc: Sebastian Ene , catalin.marinas@arm.com, james.morse@arm.com, jean-philippe@linaro.org, maz@kernel.org, Sudeep Holla , oliver.upton@linux.dev, qperret@google.com, qwandor@google.com, suzuki.poulose@arm.com, tabba@google.com, will@kernel.org, yuzenghui@huawei.com, vdonnefort@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH] KVM: arm64: Add support for FFA_PARTITION_INFO_GET Message-ID: References: <20240409151908.541589-1-sebastianene@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240411_020524_670269_DF810B0B X-CRM114-Status: GOOD ( 30.32 ) 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 Wed, Apr 10, 2024 at 04:57:19PM +0200, Lorenzo Pieralisi wrote: > On Tue, Apr 09, 2024 at 03:19:08PM +0000, Sebastian Ene wrote: > > Handle the FFA_PARTITION_INFO_GET host call inside the pKVM hypervisor > > and copy the response message back to the host buffers. Save the > > returned FF-A version as we will need it later to interpret the response > > from the TEE. > > > > Signed-off-by: Sebastian Ene > > --- > > arch/arm64/kvm/hyp/nvhe/ffa.c | 49 +++++++++++++++++++++++++++++++++++ > > 1 file changed, 49 insertions(+) > > > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c > > index 320f2eaa14a9..72fc365bc7a8 100644 > > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c > > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c > > @@ -67,6 +67,7 @@ struct kvm_ffa_buffers { > > */ > > static struct kvm_ffa_buffers hyp_buffers; > > static struct kvm_ffa_buffers host_buffers; > > +static u32 ffa_version; > > > > static void ffa_to_smccc_error(struct arm_smccc_res *res, u64 ffa_errno) > > { > > @@ -640,6 +641,49 @@ static bool do_ffa_features(struct arm_smccc_res *res, > > return true; > > } > > > > +static void do_ffa_part_get(struct arm_smccc_res *res, > > + struct kvm_cpu_context *ctxt) > > +{ > > + DECLARE_REG(u32, uuid0, ctxt, 1); > > + DECLARE_REG(u32, uuid1, ctxt, 2); > > + DECLARE_REG(u32, uuid2, ctxt, 3); > > + DECLARE_REG(u32, uuid3, ctxt, 4); > > + DECLARE_REG(u32, flags, ctxt, 5); > > + u32 off, count, sz, buf_sz; > > + > > + hyp_spin_lock(&host_buffers.lock); > > + if (!host_buffers.rx) { > > + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS); > > + goto out_unlock; > > + } > > + > > + arm_smccc_1_1_smc(FFA_PARTITION_INFO_GET, uuid0, uuid1, > > + uuid2, uuid3, flags, 0, 0, > > + res); > > + > > + if (res->a0 != FFA_SUCCESS) > > + goto out_unlock; > > + > > + count = res->a2; > > + if (!count) > > + goto out_unlock; > > + > > + if (ffa_version > FFA_VERSION_1_0) { > > + buf_sz = sz = res->a3; > > + if (sz > sizeof(struct ffa_partition_info)) > > + buf_sz = sizeof(struct ffa_partition_info); > > We are copying buf_sz but (correctly ?) returning res->a3 to the caller, > which is allowed to expect res->a3 bytes to be filled since that's what > firmware reported. > > Technically this is not a problem at present, because the caller > (ie the FF-A driver) and the hypervisor rely on the same descriptor > structures (and buf_sz can't be != sizeof(struct ffa_partition_info), > anything else is a bug as we stand); they must be kept in sync though as > the firmware version changes (*if* there are changes in the partition > descriptor - eg fields are added). > Indeed, this will break if the size of the descriptor changes in the future and the kernel has not yet added the support for that though it is unlikely as we negotiate the version and the response for all the messages should be as per the negotiated version. > An option would consist in just copying res->a3 bytes as firmware reports > (obviously keeping the RX buffer boundary checks for the memcpy). > Yes I prefer that. > It is just a heads-up because I noticed it, no more, I will let Sudeep > comment on this since he knows better. > I think you had it all covered, nothing much to add. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel