On 07.10.2026 12:43, 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. >> 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. I've dropped the entire series from dma-mapping-for-next. Aneesh, please respin it again and move the pKVM/restricted_dma_pool related code into the separate patch.
Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
