Mostafa Saleh <[email protected]> writes: > On Tue, May 19, 2026 at 07:30:16PM +0530, Aneesh Kumar K.V wrote: >> Mostafa Saleh <[email protected]> writes: >> >> >> > >> >> > I am still running more tests, but looking more into it. Setting >> >> > force_dma_unencrypted() to true for pKVM guests is wrong, as the >> >> > guest shouldn’t try to decrypt arbitrary memory as it can include >> >> > sensitive information (for example in case of virtio sub-page >> >> > allocation) and should strictly rely on the restricted-dma-pool >> >> > for that. >> >> >> >> ?? >> >> >> >> Where does force_dma_unencrypted() cause arbitary memory passed into >> >> the DMA API to be decrypted? That should never happen??? >> > >> > Sorry, maybe arbitrary is not the right expression again :) >> > I mean that, with emulated devices that use the DMA-API under pKVM, >> > they will map memory coming from other layers (VFS, net) through >> > vitrio-block, virtio-net... These can be smaller than a page, and >> > >> >> Don't we PAGE_ALIGN these requests? >> >> dma_direct_alloc >> size = PAGE_ALIGN(size); >> >> iommu_dma_alloc_pages >> size_t alloc_size = PAGE_ALIGN(size); >> >> > > For allocation, yes, and that's fine because we bring memory from > the pool. > But not for mapping, as dma_direct_map_phys(), where the memory is > allocated from the driver or other parts in the kernel and the page > may be shared with other kernel components. >
But if we are using restricted-dma-pool, we also have: mem->force_bounce = true; mem->for_alloc = true; So, will we use the swiotlb buffers for mapping and copy only the shared content into those swiotlb buffers? -aneesh
