Hi Valentin,
On Wed, Jun 24, 2015 at 03:18:24PM +0300, Valentin Manea wrote:
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 guess that there are use cases where a client gets hold of a dma_buf without 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).
The proposed api in tee.h doesn't cover memory that isn't represented by a file descriptor. A memref is represented as: struct tee_ioctl_param_memref { __u64 shm_offs; __u64 size; __s64 shm_fd; };
I see two options here: a) We add a way to represent registered shared memory with a file descriptor b) We add another parameter type, regmem
In a) we can then map this memory into another process (having tee-supplicant in mind) if needed. In b) there's no easy way of mapping the memory into another process, but perhaps easier to implement if this isn't a problem.
Either case is out of scope for patch v4, but we shouldn't make it hard to add it to tee.h later.
A) would mean one more TEE_IOC_XXX while b) would need some more bits in TEE_IOCTL_PARAMS_ATTR_TYPE_XXX. Changing TEE_IOCTL_PARAM_ATTR_TYPE_MASK to 0xff would guarantee room for all future parameter types. Another bit from the TEE_GEN_CAP_XXX bits can be used to indicate if registered shared memory is supported by a specific driver.
-- Regards, Jens