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 93D45C27C77 for ; Tue, 11 Jun 2024 15:48:07 +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=J7DC17/vaNvHXwu8P0oylR67IuNla1AFTScCqdlyO/8=; b=RidNzdYH2JY2rN 8da3I5qW+3GEpxpTFCduz2IEMl6UTZSdbxc5/FlapQcSCfOUAA8GfD+ZzUIQhfh898e+LYL2XFF/1 9f0/8PmScsrcSqlwzAksvrqQhwDsWEVV/aMV0Fj9XXU2OqKuvK1RKJWYXCp4UhCtJN5TdSYDz5Ca3 Os0doWYB6eXqh5F1YMvIAMsIa5iYmopph5sjO48J+H2FqAbJizTiS9MHYZ3UDVun6mIRiporsQtvR Sm5nU+erz1g+SymJVAKTo0rBEpgwtbqwanmjQopa7pwwNejtpCUYTOjObmoxQswR9SG2uNGgjX9vU wzkTx4W+ZdoliHHtQUaQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sH3iw-00000009ODc-2chK; Tue, 11 Jun 2024 15:47:50 +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 1sH3it-00000009OBm-3YNA for linux-arm-kernel@lists.infradead.org; Tue, 11 Jun 2024 15:47:49 +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 8C28B113E; Tue, 11 Jun 2024 08:48:09 -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 D8DD63F73B; Tue, 11 Jun 2024 08:47:43 -0700 (PDT) Date: Tue, 11 Jun 2024 16:47:41 +0100 From: Sudeep Holla To: Vincent Donnefort Cc: maz@kernel.org, oliver.upton@linux.dev, sebastianene@google.com, Sudeep Holla , will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kernel-team@android.com Subject: Re: [PATCH] KVM: arm64: FFA: Release hyp rx buffer Message-ID: References: <20240530131734.2724454-1-vdonnefort@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-20240611_084747_962193_77A01B8C X-CRM114-Status: GOOD ( 20.08 ) 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 Fri, May 31, 2024 at 06:25:46PM +0100, Vincent Donnefort wrote: > Hi Sudeep, > > On Thu, May 30, 2024 at 02:17:34PM +0100, Vincent Donnefort wrote: > > According to the FF-A spec (1.2 BET0 7.2.2.4.2), after a producer has > > written into a buffer, it is "full" and now owned by the consumer until > > it is read and "empty". This must be signaled by the consumer with the > > RX_RELEASE invocation. > > > > It is clear from the spec (7.2.2.4.2), that MEM_RETRIEVE_RESP is > > transferring the ownership from producer (in our case SPM) to consumer > > (hypervisor). We must then subsequently invoke RX_RELEASE to transfer > > back the ownership (i.e. to let SPM mark the buffer as "empty"). > > > > It is less clear though what is happening with MEM_FRAG_TX. But this > > invocation, as a response to MEM_FRAG_RX writes into the same hypervisor > > RX buffer. Also this is matching the TF-A implementation where the RX > > buffer is marked "full" during a MEM_FRAG_RX. > > Perhaps a change is needed here in the FF-A spec? Not only it seems strange that > there are no mention about MEM_FRAG_RX in the buffer ownership paragraph but > also this seems strange to have to RX_RELEASE: If one invoke MEM_FRAG_RX, that's > probably because the Rx buffer is ready to be read anyway? > Yes, it is kind of implicit. Under section "Transmission of transaction descriptor in fragments" subsection "Description", you can see the below statement(just to avoid spec document version confusion) "A Receiver must request the Sender to transmit the next fragment through an invocation of the FFA_MEM_FRAG_RX ABI". By that it means the receiver(e.g. SPM) has received the current fragment sent by the sender via FFA_MEM_FRAG_TX(or specific mem API for first fragment) and it is ready to receive the next when it invokes FFA_MEM_FRAG_RX. If you think anything can be improved, happy to take it spec authors. I may be missing to see something obvious. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel