Marek Szyprowski <[email protected]> writes: > 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. >
Once we agree on the correct way to detect the pKVM use case, I will resend the series. -aneesh
