On Tue, Apr 29, 2025 at 12:39:34PM +0530, Viresh Kumar wrote:
On 28-04-25, 07:13, Armelle Laine wrote:
The initial idea was to use different memory regions hooked to different dma hal. However, the approach taken by pKVM to hook the share abi on the memory decryption handler is not easily disabled by region or device. Hence our email to seek for a solution.
The issue is that the pKVM memory decryption handler will trigger on all DMA transfers (because the kernel assumes devices do not support memory encryption by default).
Sebastian,
One thing I wanted to clarify is that we haven't tested this path yet as we don't have a pVM to Trusty setup for now. All we have for now is host to Trusty, which doesn't hit this path.
But looking at the code, dma_direct_alloc() calls dma_set_decrypted() for calls made from the pVM kernel. It looks like this will get called for both transfer types, pVM to host and pVM to Trusty.
Hello Viresh,
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 ?
The virtio layer, for example, calls dma_alloc_coherent() for virtqueue allocation, and that should lead us here for both virtio-msg and virtio-pci code-paths.
I may be wrong (as this isn't tested for now), but we thought you guys might have already thought about such cases when the code was written and so thought of asking in advance.
-- viresh
Thanks, Sebastian