Re: Re: [PATCH] KVM: arm64: Allow smaller FF-A RX/TX buffers

>On Mon, Aug 24, 2026 at 09:53:45AM +0900, Mankyum Kim wrote:

Hello,

>Hi Sebastian,
>
>
>
>Thanks for the feedback. I took another look at the SPMC capability
>reporting and found an important detail that I missed in v1.
>
>
>
>With FF-A, the SPMC in this configuration advertises both the minimum
>and maximum RX/TX buffer sizes as 4K. `hyp_ffa_post_init()` currently
>only considers the minimum size and ignores the maximum.
>
(making it readable as the reply was sent in html format)

The max size discovery has been added from FF-A 1.2. Old SPMCs with <
1.2 will not have it.

>
>
>I agree that the host-facing FFA_FEATURES should report pKVM's RX/TX
>requirement, as you suggested. That would keep the host/pKVM mapping at
>the host page granularity and also avoid the partial-page sharing issue
>Marc pointed out.
>
>
>
>However, with a 16K host/pKVM, the host would then request:
>
>
>
>```
>
>FFA_RXTX_MAP(..., page-count=4)
>
>```
>
>
>
>and the current `ffa_map_hyp_buffers(npages)` would forward the same
>page count to the SPMC. This SPMC advertises a maximum RX/TX buffer size
>of 4K, so the 16K mapping is rejected.
>

Right, I see what you mean. In this case we would have to :

- keep track in a variable for the size of the hyp mailbox buffer
  (pkvm_ffa_bufsz) let's say

- make hyp_ffa_post_init aware of the max RX/TX discovered size if we
  are running with FF-A >= 1.2

  if max_rxtx_sz < PAGE_SIZE * KVM_FFA_MBOX_NR_PAGES:
  	pkvm_ffa_bufsz = max_rxtx_sz;

- if we are running with FF-A < 1.2:
	pkvm_ffa_bufsz = min_rxtx_sz

- update the code for the host-facing FFA_FEATURES to report
  pkvm_ffa_bufsz when queried from host and make sure we use that
  instead of the paths that use KVM_FFA_MBOX_NR_PAGES

>
>
>It therefore looks like supporting this configuration would require
>separating the host-facing RX/TX size from the SPMC-facing RX/TX size. I
>also noticed that several paths currently use `KVM_FFA_MBOX_NR_PAGES *
>PAGE_SIZE` as the capacity of the hyp buffers, so simply mapping the hyp
>buffers with a page count of one doesn't seem sufficient.
>
>
>
>I'll drop the approach taken in v1.
>
>
>
>Does this match your understanding? In particular, do you think your
>configurable mailbox work could be extended to support different
>host-facing and SPMC-facing RX/TX sizes, or would you handle that
>separately?
>
>
>
>Thanks,
>
>Mankyum

Thanks,
Sebastian