On Thu, 28 Nov 2019, Christoph Hellwig wrote: > > So we're left with making dma_pool_alloc(GFP_ATOMIC) actually be atomic > > even when the DMA needs to be unencrypted for SEV. Christoph's suggestion > > was to wire up dmapool in kernel/dma/remap.c for this. Is that necessary > > to be done for all devices that need to do dma_pool_alloc(GFP_ATOMIC) or > > can we do it within the DMA API itself so it's transparent to the driver? > > It needs to be transparent to the driver. Lots of drivers use GFP_ATOMIC > dma allocations, and all of them are broken on SEV setups currently. >
Not my area, so bear with me. Since all DMA must be unencrypted in this case, what happens if all dma_direct_alloc_pages() calls go through the DMA pool in kernel/dma/remap.c when force_dma_unencrypted(dev) == true since __PAGE_ENC is cleared for these ptes? (Ignoring for a moment that this special pool should likely be a separate dma pool.) I assume a general depletion of that atomic pool so DEFAULT_DMA_COHERENT_POOL_SIZE becomes insufficient. I'm not sure what size any DMA pool wired up for this specific purpose would need to be sized at, so I assume dynamic resizing is required. It shouldn't be *that* difficult to supplement kernel/dma/remap.c with the ability to do background expansion of the atomic pool when nearing its capacity for this purpose? I imagine that if we just can't allocate pages within the DMA mask that it's the only blocker to dynamic expansion and we don't oom kill for lowmem. But perhaps vm.lowmem_reserve_ratio is good enough protection? Beyond that, I'm not sure what sizing would be appropriate if this is to be a generic solution in the DMA API for all devices that may require unecrypted memory. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
