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..
Jason
