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

[Catalin Marinas]

On Wed, Oct 07, 2026 at 11:43:06AM +0100, Will Deacon wrote:
> On Wed, Oct 07, 2026 at 11:04:05AM +0100, Catalin Marinas wrote:
> > 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.
[...]
> > That said, such heuristics should have been a separate patch to make it
> > easier to review/drop.
> 
> I think the only right way to get a semi-accurate heuristic is to take
> into account the set of dma-capable devices that will use the swiotlb
> pool, but that's fiddly and should probably be tackled as a separate
> series. Maybe a simpler hack in that direction would be to take the
> SWIOTLB_POOL_CC_GUEST if _any_ device is going to use swiotlb? You'll
> run into the usual problem of not being able to tell if a device is
> DMA-capable or not, but you could probably look for a global restricted
> DMA pool and, if that doesn't exist, check for per-device restricted pools
> on dma-coherent devices (since restricted DMA isn't supported by ACPI) as
> a reasonable approximation.

Yes, I think that's reasonable. We'd need to drive this from the arch
code or, as you suggested, drivers/virt/coco rather than generic
heuristics in the swiotlb code.

-- 
Catalin