From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E92D12C15A0; Thu, 20 Aug 2026 08:27:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787214468; cv=none; b=VNbUCTucCWENUtOffPGq7Up9hyHoa7VMbqxt8TgYxEGTrcA3n89ahOoFFFjxZBrwJDpCDUpOWsrsaDAmkGOembhMnHShZQgk0xvEE4IsNqQpcZA8L3EXBqCcJ3wEznUBRlid6xOXoupTm7Xio5Ay9i6cvjOB34wu1+Uq/ffu15E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787214468; c=relaxed/simple; bh=XxAYKuknyCFVxVNDieD79kG/aA28qTIdmUjvhRNCt5Y=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=XZZr7AMgbdBUjt/GIjypl9JCL+VfS8rabrMiNieP//BkOxeDtLuUTtXJdZs/1yVDwdR+psEfYJ8NNDyg9sZVU53j5Hu6vnWK+ErXbekFDTKoeFbbYXyu41TVprj7whRDvp8nShmeLvifN44lZmZgHGjakBbzx82A42/eIh4x3fk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DYXIU7tR; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DYXIU7tR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E6DB1F000E9; Thu, 20 Aug 2026 08:27:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787214466; bh=3wSIzj2uvZmc1TATO8hMXymASQPPrUhb17cx77/Ar2U=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=DYXIU7tRLN8z41cLbxEoT/IT/ur5j9w/7FuOZp5Eb2p9N4bWRb8QixQ8HodW3VxaQ 8SaFeK3GefxxhAeTau85PKWlcJpRBkHyQ8A1R55P1yJX3NNeasBbpMXC9kz7FkM1Ck lQ00EuGfmZcOPC5PhMJpGvTKiJOFJLVp0MKxEGpU0YYJCp8y0rkymXvupZRoVAFatA QztiCmEp9zRtA5Rl7U6NLnobwpoP3F0wmI+A/UPrnUPdQon6xnmZiwuGhDlunkcD2/ zR+TboYIUBsfgnsOiE+AbL0VLY9nRagJTeUge1uMyIVPVucjznOCovUeBW0cOONG0Q zy0ixAtIsJVSg== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wwy7k-0000000HDEX-28j7; Thu, 20 Aug 2026 08:27:44 +0000 Date: Thu, 20 Aug 2026 09:30:16 +0100 Message-ID: <875x15p52f.wl-maz@kernel.org> From: Marc Zyngier To: mankyum.kim@samsung.com Cc: Oliver Upton , Will Deacon , Fuad Tabba , Andrew Walbran , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: Allow smaller FF-A RX/TX buffers In-Reply-To: <20260820-master-v1-1-ea602b6d3860@samsung.com> References: <20260820-master-v1-1-ea602b6d3860@samsung.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) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: mankyum.kim@samsung.com, oupton@kernel.org, will@kernel.org, fuad.tabba@linux.dev, qwandor@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 20 Aug 2026 06:42:31 +0100, Kim Mankyum via B4 Relay wrote: > > From: Kim Mankyum > > pKVM currently requires the host to map PAGE_SIZE worth of RX/TX > buffers, as do_ffa_rxtx_map() requires the FF-A page count to match > the capacity of the hypervisor RX/TX buffers. > > This is unnecessarily restrictive when the kernel page size is larger > than the minimum RX/TX buffer size advertised by the SPMC. For > example, with a 16K kernel and an SPMC advertising a minimum RX/TX > buffer size of 4K, a host request with a page count of one is rejected > by pKVM. > > hyp_ffa_post_init() already allows an SPMC whose minimum RX/TX buffer > size is smaller than PAGE_SIZE, and the page count supplied by the host > is forwarded unchanged when mapping the hypervisor buffers into the > SPMC. > > Allow RX/TX buffers smaller than the capacity of the hypervisor buffers > while continuing to reject requests which exceed it. You don't explain why this is safe. Are you guaranteed that the physical page stays accessible to the host? What happens if another range in the same physical page gets shared again? Best case, this will fail, but why is that an acceptable behaviour? You need to provide answers to these questions before we can consider this change. Thanks, M. -- Jazz isn't dead. It just smells funny.