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 3802CC25B75 for ; Fri, 31 May 2024 17:26:17 +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=58x4jxMAsdWxyMJw6b68839D1Kk6TLX6ZrB2GvqU1lQ=; b=gOYC5hrznjMZdo Ml6j5M0x8to1jglOja7KWwxwxjVSJAOKjJXVEqRVIVJE5f9VuYq7ogdJ7j6AJYvoCq2gG8zNIhooZ 6DHoh3iSnGH64DUQ3P6RyKWh0OkoaLG+DjNZWJMYQmbexG5Ggoy3G0WN8E1mnQ2o4ebwd6qg4ZSdl MZDaMDQ0KYgS6qWAJSB0aYBkhUGYt5lzTYWTagxouLH1ysFe/qTmB7nRchZTkJLAzG6fAZaDHA4vU TEFcR8zyLEydZ5BxyhASD2l/RoOxV7XMKYfG0STz9LBI7ePnC453VCQcq64puWeS5c7nWTWHL8nmb xEtpbfiwaWhTOWiY4IMw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sD60y-0000000B0Ay-242I; Fri, 31 May 2024 17:26:04 +0000 Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sD60t-0000000B09O-47Hs for linux-arm-kernel@lists.infradead.org; Fri, 31 May 2024 17:26:03 +0000 Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2e72b8931caso25010951fa.0 for ; Fri, 31 May 2024 10:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717176351; x=1717781151; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=D4Vf/r8pzEnd/o9AQIT/jZRY6M1pLsApEezlnWmF7w4=; b=TuOk1MT+qtHOTLGQLta2avIT+F7CkEGLzUH79CuB/GodNNJ2hRsTwiQM6DbxhFbDU/ 2S5wwp2pB+AVtfBV4kqmUzfTKpMnQK8uWVxyj4t7nX+ctbzNhDKjp6EbS24e1SVLNtqd JcKIQyAlQcSMiDGs2T7t/DslLpzJrpmlTRCOLxetBDu2MrHSHrRswuMatx/G5CKJ491V m8IasccXZcpxfQoMyoI7AfVYML26TNTvJ6lZJIVdlLBFl75v3JeTz0tepF/12PkV9kXo sm3Jjbs/qnar2Fe4C43MHe+RcjTxtHofbagObEiRO4AmubordK+gAgBJ+lcZPAKJaucr axsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717176351; x=1717781151; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=D4Vf/r8pzEnd/o9AQIT/jZRY6M1pLsApEezlnWmF7w4=; b=YAJH53XUl9eDr/t3t32fEglE2GWa79QnnZdR1vy4oy7ecNfSXesDNTVfv0wC5lUjhn Zc0/2HcUqedeg9oXCVvSWdDB1Ulj+XlsR8j/dk/A34tHb7qNZxKgsxJ3Oameb5lscBjW xY7P2WiGBsemXJh/rN96A9QJGBLzrCzxCarccz4ByI/PkguRwfP9LS1YKQ076o87LYbP 4gU8v2dsucVs2BHPXQTtwqzTJdEhgZzL9GLv6duSc62x3ktveJ7Xng/ACBMDR97V5D2V euRrD0wTSZQYikVzFUg15nm0PonivylhkSMr8sxRn9fR1+RYOmSXGRQ/qk1M4iRJgG3C PDvg== X-Forwarded-Encrypted: i=1; AJvYcCVcvIN6LQ8ya3UizblXS8DfpubqSIQHe6QttMsOMaNq+N8S2qj5v++F/9ls4AQu/dui2HIzJlaF80BNRd0hzAuYPwH4GU7wNXfzgx46I24utuJMz7Q= X-Gm-Message-State: AOJu0YzqRC9lVaM+R/rlQbhqLD+NH6UciGEjnRtkrSBensElQiFhp2Z5 9b/JPNEIVtdO6Ja9ycc05t8OU07DgaRERGilhy6P6mEfJWWM3JDueP/Dyy/ZOA== X-Google-Smtp-Source: AGHT+IEsiMXlDAxu6o0vW5tB+2UJaDrPXl+WD89XXcT688cmRfysvtEXYImSQr++1OCyDO92JKWYAQ== X-Received: by 2002:a05:651c:b07:b0:2e4:45a6:cdcf with SMTP id 38308e7fff4ca-2ea951d251fmr19261491fa.43.1717176350681; Fri, 31 May 2024 10:25:50 -0700 (PDT) Received: from google.com (65.0.187.35.bc.googleusercontent.com. [35.187.0.65]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-421270ad6bfsm60963615e9.46.2024.05.31.10.25.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 May 2024 10:25:50 -0700 (PDT) Date: Fri, 31 May 2024 18:25:46 +0100 From: Vincent Donnefort To: maz@kernel.org, oliver.upton@linux.dev, sudeep.holla@arm.com Cc: sebastianene@google.com, 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: <20240530131734.2724454-1-vdonnefort@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240531_102600_058835_22C528D9 X-CRM114-Status: GOOD ( 24.12 ) 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 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? > > 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). > > Signed-off-by: Vincent Donnefort > > index 02746f9d0980..efb053af331c 100644 > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c > @@ -177,6 +177,14 @@ static void ffa_retrieve_req(struct arm_smccc_res *res, u32 len) > res); > } > > +static void ffa_rx_release(struct arm_smccc_res *res) > +{ > + arm_smccc_1_1_smc(FFA_RX_RELEASE, > + 0, 0, > + 0, 0, 0, 0, 0, > + res); > +} > + > static void do_ffa_rxtx_map(struct arm_smccc_res *res, > struct kvm_cpu_context *ctxt) > { > @@ -543,16 +551,19 @@ static void do_ffa_mem_reclaim(struct arm_smccc_res *res, > if (WARN_ON(offset > len || > fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE)) { > ret = FFA_RET_ABORTED; > + ffa_rx_release(res); > goto out_unlock; > } > > if (len > ffa_desc_buf.len) { > ret = FFA_RET_NO_MEMORY; > + ffa_rx_release(res); > goto out_unlock; > } > > buf = ffa_desc_buf.buf; > memcpy(buf, hyp_buffers.rx, fraglen); > + ffa_rx_release(res); > > for (fragoff = fraglen; fragoff < len; fragoff += fraglen) { > ffa_mem_frag_rx(res, handle_lo, handle_hi, fragoff); > @@ -563,6 +574,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_res *res, > > fraglen = res->a3; > memcpy((void *)buf + fragoff, hyp_buffers.rx, fraglen); > + ffa_rx_release(res); > } > > ffa_mem_reclaim(res, handle_lo, handle_hi, flags); > > base-commit: 6d69b6c12fce479fde7bc06f686212451688a102 > -- > 2.45.1.288.g0e0cd299f1-goog > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel