On Wed, May 20, 2020 at 4:31 AM Andrew Walbran qwandor@google.com wrote:
On Tue, 19 May 2020 at 15:43, Achin Gupta achin.gupta@arm.com wrote:
Hi Andrew,
CIL...
On Tue, May 19, 2020 at 01:28:43PM +0100, Andrew Walbran wrote:
Hello, I've run into a few issues while implementing fragmentation for
memory
sharing based on the FF-A 1.0 spec, which I think need clarifying or fixing.
- From section 13.2.2.3 points 2-6, it sounds like the 'sender' in
the
Did you mean Section 12.2.2.3 in the publicly available spec [1]?
Yes, I was looking at a different version.
case of a FFA_MEM_RETRIEVE_RESP_32 from the SPM to the non-secure
hypervisor is the SPM. Am I correct in understanding that this means that the sender id for FFA_MEM_FRAG_TX and FFA_MEM_FRAG_RX should
thus
always be the ID of the SPM, when the hypervisor is retrieving a
memory
region from the SPM for the purposes of a reclaim operation from a normal world VM?
The Sender ID is really meant to be used when the Hypervisor forwards the TX and RX operations to the SPM on behalf of a VM.
In all other cases, the Sender ID field in a RX/TX operation MBZ. If this makes sense then I could update the spec.
I think that makes sense. Arve, do you agree?
It would be good to clarify this in the spec, as it is currently not very clear.
The spec already says sender-id mbz if the client is not a hypervisor, but to the SPM, that is not easily known. For frag-rx calls it would be easier if sender-if was retriever-id (the current client) and always passed. For frag-rx return values, i'm not sure it has any use. Similar for frag-tx.