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 75E2DC27C65 for ; Tue, 11 Jun 2024 16:17:32 +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=Ne4JWvEaafTOh4rkzwghEInbfMVKp5rx6PfiWVjT1cg=; b=sXZSumwIkFAal5 Bz/ftpcFrNR5nIRQuWvrk13udkKq3Hw6Ierdl7EUEcC40RESji1XpIItHqfLbRM/dldkN+laPvQBc wh3t2muw5iVHxSkOBMHbAKVY8qy4ZRBHQjNjw0XVZdkeZPujThTLaAOrcBdZ7RDG2UYv9inl6zZql 3QA8274tPCSJ4Ihl/GOdJfEmDMYQvgyFqHRw4OsSRNcNOGDp1vvMUgyQVowWW83z46NTBEgBsCBh+ Rel0rwWxCKwc3Cavu7Z6oBTXPOjRHi/+kEchsX1y417MTMbPG40vI7JeY6uBohO8VISx0DJl/l+JM 2X72OU9KWSkbfxQLk10g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sH4BO-00000009TGI-3sVs; Tue, 11 Jun 2024 16:17:14 +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 1sH4BL-00000009TEt-2mQI for linux-arm-kernel@lists.infradead.org; Tue, 11 Jun 2024 16:17:13 +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 C62811595; Tue, 11 Jun 2024 09:17:34 -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 1DBDF3F73B; Tue, 11 Jun 2024 09:17:09 -0700 (PDT) Date: Tue, 11 Jun 2024 17:17:06 +0100 From: Sudeep Holla To: Sebastian Ene Cc: Vincent Donnefort , maz@kernel.org, Sudeep Holla , oliver.upton@linux.dev, 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_091711_772496_5D919608 X-CRM114-Status: GOOD ( 26.13 ) 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 Tue, Jun 11, 2024 at 01:56:46PM +0000, Sebastian Ene wrote: > On Thu, May 30, 2024 at 02:17:34PM +0100, Vincent Donnefort wrote: > > Hello Vincent, > > > According to the FF-A spec (1.2 BET0 7.2.2.4.2), after a producer has I prefer to drop all these section and spec version details as it may be stale info in few months time. Better to just refer the section by name if you are referring non release versions of the document. > > 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. > > I agree the spec is a bit unclear in the ownership transfer of the buffer: > - it mentions that the producer owns it when it is empty (I think it is > a separate state the ownership transfer than being "full"). Some FF-A I think above statement might add more confusion than clarity IMO. > ABIs do the ownership transfer when they are invoked, but not all of > them and this is why we need calls like RX_RELEASE, to signal the > availability of the buffer and to transfer the ownership from the > Consumer to the Producer. Can we add this explanation as part of the > commit message to justify why we need this ? > This part looks good and can be added. But IMO, not a must, I am fine either way. Sorry I don't know how else to improve the commit message. > I think it is also worth mentioning that this is how TF-A (Trusted > Firmware) deals with the ownership transfer of the buffer. > > > > > 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"). > > This section clarifies the need for this patch IMO. So I am fine with it as along as the above info is present. > > 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. > > I have responded to this separately, hope that makes sense. You can even drop this section. I am fine either way. > > Release the RX hypervisor buffer in those two cases. This will unblock > > later invocations using this buffer which would otherwise fail. > > (RETRIEVE_REQ, MEM_FRAG_RX and PARTITION_INFO_GET). > > > The change itself looks good to me. Reviewed-by: Sudeep Holla -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel