Hi all,
On Wed, Apr 30, 2025 at 4:40 PM Sebastian Ene sebastianene@google.com wrote:
On Wed, Apr 30, 2025 at 04:30:26PM +0530, Viresh Kumar wrote:
On 30-04-25, 10:54, Sebastian Ene wrote:
Looking at vring_alloc_queue, if VIRTIO_F_ACCESS_PLATFORM is not set in we don't end up on the dma_alloc APIs and we avoid the set_memory_decrypted path. Instead pages will be allocated with alloc_pages_exact which is what I suggested earlier.
The feature set seems to be returned by the device in response to the VIRTIO_MSG_GET_FEATURES call.
The VIRTIO_F_ACCESS_PLATFORM feature is enabled in our case. And we need to use the dma_alloc APIs, as we want our virtio-msg specific DMA HAL to take care of memory mapping over FFA. We do need dma_alloc_coherent() to be called here.
Right I see, in that case I wonder if it makese sense to have a new property in the DT for the reserved-memory region which informs the swiotlb driver to not call `set_memory_decrypted` upon region initialization. By doing this we don't end up with the memory shared with the host and you can continue using the DMA HAL which takes care of the FF-A mapping.
Not my area of expertise, but by a quick eyeball at the code it seems that there is already per-device logic to skip the set_memory_decrypted() calls and such. Specifically, force_dma_unencrypted(dev) does that, although it seems to only be plumbed with CC-A specific logic. Could that be extended for this use-case?