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

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Will Deacon <will@kernel.org> writes:

> 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.
>> 
>> 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.
>
> Hrm, that does mean that reverting just this part will regress pVMs
> because they'll suddenly be allocating a tonne more memory for an
> entirely unused swiotlb buffer. So I think I'd prefer to drop the entire
> series until this has been worked out properly.
>
>> 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.
>
> At that point, the default size may as well be driven by the
> drivers/virt/coco driver.
>
>> 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.

So, something like this?

	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) &&
	    swiotlb_cc_guest_needs_default_pool())
		return SWIOTLB_POOL_CC_GUEST;

where:

static bool swiotlb_cc_guest_needs_default_pool(void)
{
	for_each_of_allnodes(np) {
		if (swiotlb_of_dma_needs_default_pool(np))
			return true;
	}

	return false;
}

I didn't quite follow the ACPI-related feedback. IIUC, on ACPI systems
we will end up using SWIOTLB_POOL_CC_GUEST?

-aneesh