On Thu, 11 Jun 2026 08:37:40 -0300 Jason Gunthorpe <[email protected]> wrote:
> On Thu, Jun 11, 2026 at 10:55:47AM +0530, Aneesh Kumar K.V wrote: > > Jason Gunthorpe <[email protected]> writes: > > > > > The sashiko note does look legit though: > > > > > > if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && > > > !gfpflags_allow_blocking(gfp) && !coherent) { > > > page = dma_alloc_from_pool(dev, PAGE_ALIGN(size), &cpu_addr, > > > gfp, attrs, NULL); > > > if (!page) > > > return NULL; > > > > > > I don't see anything doing the force_dma_unencrypted test along this > > > callchain.. > > > > > > I guess it should be done one step up in dma_alloc_attrs() instead of > > > in dma_direct_alloc()? > > > > > > > I think we should do something similar to what dma_map_phys() does here, > > considering that we only support DMA direct with > > DMA_ATTR_CC_SHARED/DMA_ATTR_ALLOC_CC_SHARED. > > Yeah, I think that's the right idea for now.. > > > + if (force_dma_unencrypted(dev)) > > + attrs |= DMA_ATTR_ALLOC_CC_SHARED; > > + > > + is_cc_shared = attrs & DMA_ATTR_CC_SHARED; > > + > > if (dma_alloc_direct(dev, ops) || arch_dma_alloc_direct(dev)) { > > cpu_addr = dma_direct_alloc(dev, size, dma_handle, flag, attrs); > > + } else if (is_cc_shared) { > > + trace_dma_alloc(dev, NULL, 0, size, DMA_BIDIRECTIONAL, flag, > > + attrs); > > But it would be clearer to put the test in the iommu_ functions I > think, since they are the ones that have the issue. We will need to > fix it someday.. > > I think we can ignore the op-> functions, arches cannot support CC and > still use dma_map_ops.. Hm, sounds reasonable. Should we probably enforce this at configure or build time? Petr T
