Re: [PATCH v6 6/8] dma: swiotlb: Centralize memory-encryption pool sizing

[Catalin Marinas]

On Tue, Oct 06, 2026 at 10:49:17PM +0100, Will Deacon wrote:
> On Thu, Sep 24, 2026 at 11:37:54AM +0530, Aneesh Kumar K.V (Arm) wrote:
> > @@ -496,7 +516,8 @@ swiotlb_select_pool_policy(unsigned int flags)
> >  	if (swiotlb_force_disable)
> >  		return SWIOTLB_POOL_NONE;
> >  
> > -	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
> > +	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
> > +	    !restricted_dma_pool_present)
> >  		return SWIOTLB_POOL_CC_GUEST;
> 
> I think this check on the restricted DMA pool is too general -- the pool
> could be tied to a specific DMA-capable peripheral and so treating its
> presence as a global property isn't right.

I agree it's a hack but that was the simplest way to avoid the pVMs
getting a bounce buffer after this patch. More than happy to leave it
out and reduce the buffer on cmdline or we come up with some better
heuristics.

Another option could be the arch code passing another flag that it
doesn't want an encrypted pool (e.g. when running in a pKVM guest) but I
don't particularly this either. The arch code doesn't know whether
there's an alternative pool.

That said, such heuristics should have been a separate patch to make it
easier to review/drop.

-- 
Catalin