From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 77684CA6002 for ; Thu, 8 Oct 2026 05:34:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bUTtvirUzfAWPpw8iHXZO6VhEiVPFeKOeaX4qaE57Bk=; b=4CmI16fDMJdFkd NeoIZH63CigH1RsfGuReNHBSJ0CRZ+N/HtgI9Wxnrg5oBSCj2+qF5aPzYPVFckwHA+RV3efrzIAHC pnz5Dw738fSxwXRIW22siNZIEiQwwWrMBbjOlvCZUh/Ih8aO4FR+l9yXabg4ePng46IaYBGsIjkWq 4fc12CKUDgzvc7PciEGpxiL9eug49EE5QRp6S4Qs2Df/6/R+qUlI0aM60M6Bey9G3lz+5QlQLSu9a SCu/UyoWNfPTZ5pFXCSF+VFvS1A4bOE/nfFYwI06L94euWKDC3af6Aw6V9F2yvyWQGfHPSvC3wxU8 abVK+QY8xe2IdlBbrx/A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEglH-00000003Y0l-2iod; Thu, 08 Oct 2026 05:33:47 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEglF-00000003Y0R-3f40; Thu, 08 Oct 2026 05:33:45 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id C069A60252; Thu, 8 Oct 2026 05:33:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADBD61F000FF; Thu, 8 Oct 2026 05:33:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791437624; bh=DiCB3zTU35Q/So7+8YpTI1O1VNazQCwPsoCqXsbVCxA=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=MlFvX1x1UhWZRY1blp5vdgZEPOMCBXQinqSZI84kOfHvYoEphDSM4c94C8k0YCneZ +CvWpN13IHO40ySHjg36SGLM6p3x45bPMR627QwPtHEOxGz1S8+sT5TicHHAqfnwbg bqFKdwKME2OoCRwQAo2p4meLpit9e42WrSXDC9nPxddpD1ycCgJPlJjEd5pDoDOqWs ennUOXzrVpLk3Kqhf1z0mNeMc81DduJcnqdwFkPFglVDZ80bS0a6JisTfrcpB+qHEQ B2B7dFO8dNiI2LLj/G2xvndmsNBdA4U85+1Ksxk77R/C0BzNaKttWJhMVtqisJgUfF 7H/HlTSl2Xjzw== X-Mailer: emacs 31.1 (via feedmail 11-beta-1 I) From: Aneesh Kumar K.V To: Will Deacon , Catalin Marinas Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Robin Murphy , Marek Szyprowski , Jonathan Corbet , Shuah Khan , Randy Dunlap , Mark Rutland , Marc Zyngier , Steven Price , Suzuki K Poulose , Jiri Pirko , Jason Gunthorpe , Mostafa Saleh , Petr Tesarik , Alexey Kardashevskiy , Dan Williams , Xu Yilun , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , "Ritesh Harjani (IBM)" , Shrikanth Hegde , Alexander Gordeev , Gerald Schaefer , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , Stefano Stabellini , Russell King , Huacai Chen , WANG Xuerui , Thomas Bogendoerfer , Jiaxun Yang , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH v6 6/8] dma: swiotlb: Centralize memory-encryption pool sizing In-Reply-To: References: <20260924060756.1325156-1-aneesh.kumar@kernel.org> <20260924060756.1325156-7-aneesh.kumar@kernel.org> Date: Thu, 08 Oct 2026 11:03:27 +0530 Message-ID: MIME-Version: 1.0 X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org Aneesh Kumar K.V writes: > Will Deacon 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; > Detecting a DMA-capable device is not straightforward, and if we get it wrong, we will enable SWIOTLB_POOL_CC_GUEST unnecessarily. Would the code below be a reasonable approximation of what you suggested? Another option would be to make swiotlb_cc_guest_needs_default_pool() a weak function that architectures can override. arm64 pKVM could then use a different scheme (for this patch series default to false). Would that be preferable? #ifdef CONFIG_DMA_RESTRICTED_POOL static bool __init swiotlb_of_dma_candidate(struct device_node *np) { struct device_node *node __free(device_node) = of_node_get(np); /* * Ignore nodes that don't have compatible and reg property * So we don't wrongly consider a node as device node. */ if (!of_property_present(np, "compatible") || !of_property_present(np, "reg")) return false; while (node) { if (!of_device_is_available(node)) return false; /* * Ignore reserved-memory nodes because that have compatible * and reg property */ if (node->parent == of_root && of_node_name_eq(node, "reserved-memory")) return false; node = of_get_next_parent(node); } return of_dma_is_coherent(np); } static bool __init swiotlb_of_dma_needs_default_pool(struct device_node *np) { if (!of_dma_get_restricted_pool(np)) return true; return false; } #endif static bool __init swiotlb_cc_guest_needs_default_pool(void) { #ifdef CONFIG_DMA_RESTRICTED_POOL struct device_node *np; bool found = false; if (!of_root) return true; /* * DMA capability is not explicitly described for every DT device. * Use coherent, addressed device nodes as an approximation, and keep * guest sizing unless every candidate has an initialized restricted * pool. */ for_each_of_allnodes(np) { if (!swiotlb_of_dma_candidate(np)) continue; found = true; if (swiotlb_of_dma_needs_default_pool(np)) return true; } return !found; #else return true; #endif } _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv