Hi Sumit,
On Fri, 15 May 2020 at 07:55, Sumit Garg sumit.garg@linaro.org wrote:
Hi Volodymyr,
On Fri, 15 May 2020 at 06:32, Volodymyr Babchuk vlad.babchuk@gmail.com wrote:
Hi Sumit,
On Thu, 14 May 2020 at 08:38, Sumit Garg sumit.garg@linaro.org wrote:
Hi Volodymyr,
On Thu, 14 May 2020 at 06:48, Volodymyr Babchuk vlad.babchuk@gmail.com wrote:
Hi Sumit,
On Wed, 13 May 2020 at 11:24, Sumit Garg sumit.garg@linaro.org wrote:
Hi Volodymyr,
On Wed, 13 May 2020 at 13:30, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi Volodymyr,
On Wed, May 13, 2020 at 2:36 AM Volodymyr Babchuk vlad.babchuk@gmail.com wrote: > > optee_enumerate_devices() can fail for multiple of reasons. For > example, I encountered issue when Xen OP-TEE mediator NACKed > PTA_CMD_GET_DEVICES call.
Could you share a detailed description of the issue which you are facing? optee_enumerate_devices() is a simple invocation of pseudo TA and cases where OP-TEE doesn't provide corresponding pseudo TA are handled very well.
Yes, I did some research and looks like issue is broader, than I expected. It is my fault, that I wasn't paying attention to the tee client support in the kernel. Basically, it is incompatible with the virtualization feature. You see, the main issue with virtual machines is the second stage MMU. Intermediate physical address, that appear to be contiguous for the kernel may be not contiguous in the real physical memory due to 2nd stage MMU mappings. This is the reason I introduced OPTEE_MSG_ATTR_NONCONTIG in the kernel driver.
But, looks like kernel-side optee client does not use this feature. It tries to provide SHM buffer as a simple contiguous span of memory. Xen blocks calls with OPTEE_MSG_ATTR_TYPE_TMEM_* but without OPTEE_MSG_ATTR_NONCONTIG , because it can't translate IPAs to PAs for such buffers. This is why call to PTA_CMD_GET_DEVICES fails.
Valid fix would be to use OPTEE_MSG_ATTR_NONCONTIG whenever possible.
Thanks for the detailed analysis. It looks like you are missing the following fix patch in your tree which basically fixed broken tee_shm_alloc() in case dynamic shared memory is enabled (IIRC virtualization only supports dynamic shared memory).
commit a249dd200d03791cab23e47571f3e13d9c72af6c
Actually, I have this patch in my tree. So, it does not fixes the issue. Which is weird, actually. I'm planning to look deeper into this.
AFAICT, the only difference here is that it's the kernel memory registered rather than user-space memory. But I am not very conversant with the Xen environment. So I hope you will be able to find the root cause as to why Xen is blocking this invocation.
Yes. I have found issue in Xen mediator code. It didn't allowed TMEM with NULL buf_ptr and without ATTR_NONCONTIG flag. This is clearly a bug and I already sent the patch to Xen ML.