Hi Viresh,
On 29 Jan 2026, at 08:43, Viresh Kumar viresh.kumar@linaro.org wrote:
On 29-01-26, 07:24, Achin Gupta wrote:
The problem of lending memory is more generic than FF-A. E.g. In Arm CCA memory is lent to the RMM by the Host. FF-A is just a mechanism to convey lent memory to the Borrower.
Absolutely.
Is the key issue not that we need to enlighten dma-buf about the concept of lent memory/secure heap/protected memory?
This is the first level problem, yes, and some part of it can be solved by enhancing the dma-buf API, for example by adding something like:
struct dma_buf_attachment * dma_buf_attach_with_flags(struct dma_buf *dmabuf, struct device *dev, u32 flags);
where the caller (Vsock) can send LEND/SHARE/etc in flags.
The problem I am stuck with is how to pass this special flag (behavior) via dma-ops to the core code making the change, i.e. virtio-msg FFA in this case.
Shouldn't we add a new op to dma_ops so that it would also be easier to detect if a dma engine supports or not LEND ?
This would keep the current op fully compatible and have a clear way to identify and reject lend request on engine not supporting it.
Bertrand
Could this not be solved by implementing a generic secure system heap as a "lend" equivalent of the existing system heap that is used for sharing memory. I believe this idea has been considered and vendor specific heaps are an intermediate step [1]?
-- viresh
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.