From patchwork Tue May 26 12:59:52 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: You-Sheng Yang X-Patchwork-Id: 1298011 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 49WYyx5qjnz9sTC; Tue, 26 May 2020 23:02:33 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1jdZDw-0005MZ-1z; Tue, 26 May 2020 13:02:28 +0000 Received: from mail-pl1-f193.google.com ([209.85.214.193]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jdZDQ-0004uh-03 for kernel-team@lists.ubuntu.com; Tue, 26 May 2020 13:01:56 +0000 Received: by mail-pl1-f193.google.com with SMTP id x18so7547957pll.6 for ; Tue, 26 May 2020 06:01:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=lklz5WdR2abizsJplp20c6C+bW81YKoe1XVeA9+8fIU=; b=Q3fRRKReBxMQJY14jtH47GqLXc1Jd/W1FZeho6S2BrSQAxh4blHlFK89XGhQh6qEVf wwZix9ByWTlHjt0ZqVQqPnVCRe9dgusrpXirzXsWkLZkQuFBUueeRa3sXYkisFiHC6cz ZYu61IP3Ly1dof1dkDzJ2EyddseTk04QU5qgnIqojW+8zOgBm0NHilTXaUFOn8UsOPBq Cr4ajReAIOrnUh3Pok+9LGMEYfZOnneHY5gxPtp9jhRVuc/PtI6KulBq4uXzun1DzaP1 tcCtuvK8C8JlLZGc83QQACarYA9NVyoWVAqGZkbhSZkOyKDb9M5a4BMvvR9C/pzqYcER sIuQ== X-Gm-Message-State: AOAM531miN+A7m7yX0Pgu1FfgY6eFjkhZd9VbNg8jVLX/4U+yE8pSiir Bl1hH2t8R3ZxLmPACplCxajeJPv0qYM= X-Google-Smtp-Source: ABdhPJxmOBwt7yIVmKliNUZi3JLweDOm5IZ64BC/b94Y62/nFLgIy9AyOGm+zWlTsBcQOzyCx78G4Q== X-Received: by 2002:a17:90a:ad86:: with SMTP id s6mr25877168pjq.193.1590498112037; Tue, 26 May 2020 06:01:52 -0700 (PDT) Received: from localhost (61-220-137-37.HINET-IP.hinet.net. [61.220.137.37]) by smtp.gmail.com with ESMTPSA id q185sm4817015pfb.82.2020.05.26.06.01.50 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 May 2020 06:01:51 -0700 (PDT) From: You-Sheng Yang To: kernel-team@lists.ubuntu.com Subject: [PATCH 40/42][SRU][U] UBUNTU: SAUCE: iommu/vt-d: Allow PCI sub-hierarchy to use DMA domain Date: Tue, 26 May 2020 20:59:52 +0800 Message-Id: <20200526125954.237403-41-vicamo.yang@canonical.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200526125954.237403-1-vicamo.yang@canonical.com> References: <20200526125954.237403-1-vicamo.yang@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Lu Baolu BugLink: https://bugs.launchpad.net/bugs/1876707 Before commit fa954e6831789 ("iommu/vt-d: Delegate the dma domain to upper layer"), Intel IOMMU started off with all devices in the identity domain, and took them out later if it found they couldn't access all of memory. This required devices behind a PCI bridge to use a DMA domain at the beginning because all PCI devices behind the bridge use the same source-id in their transactions and the domain couldn't be changed at run-time. Intel IOMMU driver is now aligned with the default domain framework, there's no need to keep this requirement anymore. Signed-off-by: Lu Baolu Tested-by: Daniel Drake Reviewed-by: Jon Derrick Reviewed-by: Jerry Snitselaar Link: https://lore.kernel.org/r/20200506015947.28662-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel (cherry picked from commit 14b3526d5909f01e1d1baa05f50952788bb7418e iommu/next) Signed-off-by: You-Sheng Yang --- drivers/iommu/intel-iommu.c | 25 ------------------------- 1 file changed, 25 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 16ba7add0f72..af309e8fa6f5 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -2857,31 +2857,6 @@ static int device_def_domain_type(struct device *dev) if ((iommu_identity_mapping & IDENTMAP_GFX) && IS_GFX_DEVICE(pdev)) return IOMMU_DOMAIN_IDENTITY; - - /* - * We want to start off with all devices in the 1:1 domain, and - * take them out later if we find they can't access all of memory. - * - * However, we can't do this for PCI devices behind bridges, - * because all PCI devices behind the same bridge will end up - * with the same source-id on their transactions. - * - * Practically speaking, we can't change things around for these - * devices at run-time, because we can't be sure there'll be no - * DMA transactions in flight for any of their siblings. - * - * So PCI devices (unless they're on the root bus) as well as - * their parent PCI-PCI or PCIe-PCI bridges must be left _out_ of - * the 1:1 domain, just in _case_ one of their siblings turns out - * not to be able to map all of memory. - */ - if (!pci_is_pcie(pdev)) { - if (!pci_is_root_bus(pdev->bus)) - return IOMMU_DOMAIN_DMA; - if (pdev->class >> 8 == PCI_CLASS_BRIDGE_PCI) - return IOMMU_DOMAIN_DMA; - } else if (pci_pcie_type(pdev) == PCI_EXP_TYPE_PCI_BRIDGE) - return IOMMU_DOMAIN_DMA; } return 0;