On 29-04-25, 16:55, Sebastian Ene wrote:
Looking at virtio_msg_dma_alloc you use dma_direct_alloc which in turn calls __dma_direct_alloc_pages which in turn calls dma_direct_alloc_swiotlb. I assume all the memory has already been shared with the host for this swiotlb by a call to set_memory_decrypted from the swiotlb init code.
Am I following it correctly ?
Why did we choose to use the swiotlb reserved memory region to bake this allocations from ? Can't we just alloc_page() from the implemented virtio_msg_ffa_dma_ops layer ?
Lets try to simplify this a bit.
Yes we are going to likely use "reserved-memory" regions eventually along with swiotlbs (for bounce buffers) to avoid mapping memory on the fly, but that can be ignored for now.
Lets say we do on-demand mapping only, no advance mapping for buffers.
I earlier thought that the call chain would be like this:
vring_alloc_queue->dma_alloc_coherent->dma_direct_alloc->dma_set_decrypted
This will likely be the call path for pVM to Host transfers (with virtio-pci).
I thought the same may end up getting triggered for pVM to Trusty too, but now I wonder if it will go to dma_direct_alloc() or not ? With our own DMA HAL for virtio-msg-ffa, we may end up following ops->alloc() path instead. If dma_direct_alloc() isn't called in our case, we may not have the problem in pVM to Trusty case.
It would be more clear once we have a setup to check this :(