Hi Jens,
On 2015-06-24 12:32, Jens Wiklander wrote:
*Non-zero copy* When using RegisterSharedMemory(), it looks we do not benefit from the fact that the original buffer was allocated using dma_buf. Hence we never have zero-copy in the current version when using RegisterSharedMemory as we will furher use the so-called shadowbuffer. Can you confirm this limitation can be removed in further versions of the patch?
How can TEEC_RegisterSharedMemory() tell if the supplied memory range is backed by a dma_buf? Perhaps we can add another TEE_IOC_XXX to given an address get a file descriptor etc needed to use that memory as shared memory. The supplied address must of course be within a range of a mmaped dma_buf for it to work.
Another option would be to extend TEE Client API with a way of initializing a TEEC_SharedMemory based on a given dma_buf.
Yes, I think it should be possible to remove this limitation in future versions.
I agree here with Pascal, having the ability to do RegisterSharedMemory is important. I always assumed the RegisterSharedMemory API was meant to be called on any memory range inside the Client memory space, not necessarily on dma-buff allocated memory. The point is that RegisterSharedMemory would be called on memory that we know is not dmabuff(for dmabuff we already have AllocateSharedMemory). I was thinking maybe the driver implementation chooses how to handle the buffer: * in some cases where 1:1 memory mapping(or contiguous memory space) is needed then copy * in other cases create some mapping table directly from the buffer(zero copy option).
Regards, Valentin