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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2EFE8C3A5A2 for ; Fri, 23 Aug 2019 08:40:02 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0F1E122CEC for ; Fri, 23 Aug 2019 08:40:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0F1E122CEC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=8bytes.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id ABB24D8C; Fri, 23 Aug 2019 08:40:01 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BA345C75 for ; Fri, 23 Aug 2019 08:39:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from theia.8bytes.org (8bytes.org [81.169.241.247]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 493037FB for ; Fri, 23 Aug 2019 08:39:59 +0000 (UTC) Received: by theia.8bytes.org (Postfix, from userid 1000) id 91BBF246; Fri, 23 Aug 2019 10:39:57 +0200 (CEST) Date: Fri, 23 Aug 2019 10:39:56 +0200 From: Joerg Roedel To: Lu Baolu Subject: Re: [PATCH v7 1/7] iommu/vt-d: Don't switch off swiotlb if use direct dma Message-ID: <20190823083956.GB24194@8bytes.org> References: <20190823071735.30264-1-baolu.lu@linux.intel.com> <20190823071735.30264-2-baolu.lu@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190823071735.30264-2-baolu.lu@linux.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Cc: alan.cox@intel.com, Christoph Hellwig , Stefano Stabellini , ashok.raj@intel.com, Jonathan Corbet , pengfei.xu@intel.com, Ingo Molnar , David Woodhouse , kevin.tian@intel.com, Konrad Rzeszutek Wilk , Steven Rostedt , Bjorn Helgaas , Boris Ostrovsky , mika.westerberg@linux.intel.com, Juergen Gross , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, jacob.jun.pan@intel.com, Robin Murphy X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org On Fri, Aug 23, 2019 at 03:17:29PM +0800, Lu Baolu wrote: > --- a/drivers/iommu/intel-iommu.c > +++ b/drivers/iommu/intel-iommu.c > @@ -4569,9 +4569,6 @@ static int __init platform_optin_force_iommu(void) > iommu_identity_mapping |= IDENTMAP_ALL; > > dmar_disabled = 0; > -#if defined(CONFIG_X86) && defined(CONFIG_SWIOTLB) > - swiotlb = 0; > -#endif > no_iommu = 0; > > return 1; > @@ -4710,9 +4707,6 @@ int __init intel_iommu_init(void) > } > up_write(&dmar_global_lock); > > -#if defined(CONFIG_X86) && defined(CONFIG_SWIOTLB) > - swiotlb = 0; > -#endif So this will cause the 64MB SWIOTLB aperture to be allocated even when there will never be an untrusted device in the system, right? I guess this will break some kdump setups as they need to resize their low memory allocations to make room for the aperture because of this patch-set. But I also don't see a way around this for now as untrusted devices are usually hotplugged and might not be present at boot. So we can't make the decision about the allocation at boot time. But this mechanism needs to be moved to the dma-iommu implementation at some point, and then we should allocate the bounce memory pages on-demand. We can easily do this in page-size chunks and map them together with iommu page-tables. This way we don't need to pre-allocate a large memory-chunk at boot. Regards, Joerg _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu