From nobody Sat Feb 7 16:00:06 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E27C75A10E for ; Tue, 20 Feb 2024 07:05:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708412742; cv=none; b=FHf1MUvD9sj1qv/WXG89Rt12mLvBspzV3sMmwmkBkNcqiCW8q1AH2k79h85riIWxKpSLEKg9Vq37PSgaT6nszTT+dt8k59AHybUAC1IAZqsCRe/Ni8OUNeYmuB3COWk3CVKAh5mByzq2vuS5Io6R7kuAJIK/8J3ifTFInHwVqOM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708412742; c=relaxed/simple; bh=zPMYb8T01iUrJHQctk16vFfd7/Rkjuot0PPcWuhjqHQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Z3BBpjV/ty7lqmRnSB743YOYCTrMX467WQ25ZeWHMFsHdPmj2miMnO7XH12h3EP9KsbUZ9vy34BwBy6YOeTDj2H3vDMh2slJJx+J6ILl3D/Tm6rjSoZjh+NUPKsNbbjTIdFpZ3h7UinxaOfQsKFl+7QQOzvYSEIN09beX94MEf8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=WX8AXyZM; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="WX8AXyZM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708412741; x=1739948741; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=zPMYb8T01iUrJHQctk16vFfd7/Rkjuot0PPcWuhjqHQ=; b=WX8AXyZMyi11JQp2My2UDfjB4bS0vLuG/0lmwkhywOTL5aqv4E1I6tah z04xnvDnsskA/C3u3icao0yELXIZ/tu+lSuZUQetcSstTHN6EJaVIsvvT 3yyUl8VlCpTcYNz1sgOJV/uyjHcCIMwRZB8Sjn30F7YLm6KAURmjaiRKf 8yGIKzi8/DOSmDnTYsgvtiEpGraNMXgv3/aYB83TEbGepeyhfztQCJwXY GLW4gDOozy5rJkPdHh/KTb1cN6aHCJKG8SbSXZ1Sb3BdqyIUCk9PWeRkm HGHu+9E/A6S7QFa66oEBG9SiYNiZAMlL8lV0F6zgPnhX5be+1MohqgpOT A==; X-IronPort-AV: E=McAfee;i="6600,9927,10989"; a="2366570" X-IronPort-AV: E=Sophos;i="6.06,172,1705392000"; d="scan'208";a="2366570" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2024 23:05:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,172,1705392000"; d="scan'208";a="4683775" Received: from allen-box.sh.intel.com ([10.239.159.127]) by fmviesa010.fm.intel.com with ESMTP; 19 Feb 2024 23:05:37 -0800 From: Lu Baolu To: Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian Cc: Huang Jiaqing , Ethan Zhao , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Lu Baolu , Jason Gunthorpe Subject: [PATCH v2 1/2] iommu/vt-d: Use rbtree to track iommu probed devices Date: Tue, 20 Feb 2024 14:59:38 +0800 Message-Id: <20240220065939.121116-2-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240220065939.121116-1-baolu.lu@linux.intel.com> References: <20240220065939.121116-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Use a red-black tree(rbtree) to track devices probed by the driver's probe_device callback. These devices need to be looked up quickly by a source ID when the hardware reports a fault, either recoverable or unrecoverable. Fault reporting paths are critical. Searching a list in this scenario is inefficient, with an algorithm complexity of O(n). An rbtree is a self-balancing binary search tree, offering an average search time complexity of O(log(n)). This significant performance improvement makes rbtrees a better choice. Furthermore, rbtrees are implemented on a per-iommu basis, eliminating the need for global searches and further enhancing efficiency in critical fault paths. The rbtree is protected by a spin lock with interrupts disabled to ensure thread-safe access even within interrupt contexts. Co-developed-by: Huang Jiaqing Signed-off-by: Huang Jiaqing Signed-off-by: Lu Baolu Reviewed-by: Jason Gunthorpe --- drivers/iommu/intel/iommu.h | 8 ++++ drivers/iommu/intel/dmar.c | 3 +- drivers/iommu/intel/iommu.c | 88 ++++++++++++++++++++++++++++++++++++- 3 files changed, 96 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index eaef932ad7c9..2b67ad0d6fe9 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -722,6 +722,11 @@ struct intel_iommu { struct q_inval *qi; /* Queued invalidation info */ u32 iommu_state[MAX_SR_DMAR_REGS]; /* Store iommu states between suspend = and resume.*/ =20 + /* rb tree for all probed devices */ + struct rb_root device_rbtree; + /* protect the device_rbtree */ + spinlock_t device_rbtree_lock; + #ifdef CONFIG_IRQ_REMAP struct ir_table *ir_table; /* Interrupt remapping info */ struct irq_domain *ir_domain; @@ -755,6 +760,8 @@ struct device_domain_info { struct intel_iommu *iommu; /* IOMMU used by this device */ struct dmar_domain *domain; /* pointer to domain */ struct pasid_table *pasid_table; /* pasid table */ + /* device tracking node(lookup by PCI RID) */ + struct rb_node node; #ifdef CONFIG_INTEL_IOMMU_DEBUGFS struct dentry *debugfs_dentry; /* pointer to device directory dentry */ #endif @@ -1081,6 +1088,7 @@ void free_pgtable_page(void *vaddr); void iommu_flush_write_buffer(struct intel_iommu *iommu); struct iommu_domain *intel_nested_domain_alloc(struct iommu_domain *parent, const struct iommu_user_data *user_data); +struct device *device_rbtree_find(struct intel_iommu *iommu, u16 rid); =20 #ifdef CONFIG_INTEL_IOMMU_SVM void intel_svm_check(struct intel_iommu *iommu); diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index 23cb80d62a9a..f9b63c2875f7 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -1095,7 +1095,8 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd) iommu->agaw =3D agaw; iommu->msagaw =3D msagaw; iommu->segment =3D drhd->segment; - + iommu->device_rbtree =3D RB_ROOT; + spin_lock_init(&iommu->device_rbtree_lock); iommu->node =3D NUMA_NO_NODE; =20 ver =3D readl(iommu->reg + DMAR_VER_REG); diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 61bb35046ea4..acfe27bd3448 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -96,6 +96,81 @@ static phys_addr_t root_entry_uctp(struct root_entry *re) return re->hi & VTD_PAGE_MASK; } =20 +static int device_rid_cmp_key(const void *key, const struct rb_node *node) +{ + struct device_domain_info *info =3D + rb_entry(node, struct device_domain_info, node); + const u16 *rid_lhs =3D key; + + if (*rid_lhs < PCI_DEVID(info->bus, info->devfn)) + return -1; + + if (*rid_lhs > PCI_DEVID(info->bus, info->devfn)) + return 1; + + return 0; +} + +static int device_rid_cmp(struct rb_node *lhs, const struct rb_node *rhs) +{ + struct device_domain_info *info =3D + rb_entry(lhs, struct device_domain_info, node); + u16 key =3D PCI_DEVID(info->bus, info->devfn); + + return device_rid_cmp_key(&key, rhs); +} + +/* + * Looks up an IOMMU-probed device using its source ID. + * + * Returns the pointer to the device if there is a match. Otherwise, + * returns NULL. + * + * Note that this helper doesn't guarantee that the device won't be + * released by the iommu subsystem after being returned. The caller + * should use its own synchronization mechanism to avoid the device + * being released during its use if its possibly the case. + */ +struct device *device_rbtree_find(struct intel_iommu *iommu, u16 rid) +{ + struct device_domain_info *info =3D NULL; + struct rb_node *node; + unsigned long flags; + + spin_lock_irqsave(&iommu->device_rbtree_lock, flags); + node =3D rb_find(&rid, &iommu->device_rbtree, device_rid_cmp_key); + if (node) + info =3D rb_entry(node, struct device_domain_info, node); + spin_unlock_irqrestore(&iommu->device_rbtree_lock, flags); + + return info ? info->dev : NULL; +} + +static int device_rbtree_insert(struct intel_iommu *iommu, + struct device_domain_info *info) +{ + struct rb_node *curr; + unsigned long flags; + + spin_lock_irqsave(&iommu->device_rbtree_lock, flags); + curr =3D rb_find_add(&info->node, &iommu->device_rbtree, device_rid_cmp); + spin_unlock_irqrestore(&iommu->device_rbtree_lock, flags); + if (WARN_ON(curr)) + return -EEXIST; + + return 0; +} + +static void device_rbtree_remove(struct device_domain_info *info) +{ + struct intel_iommu *iommu =3D info->iommu; + unsigned long flags; + + spin_lock_irqsave(&iommu->device_rbtree_lock, flags); + rb_erase(&info->node, &iommu->device_rbtree); + spin_unlock_irqrestore(&iommu->device_rbtree_lock, flags); +} + /* * This domain is a statically identity mapping domain. * 1. This domain creats a static 1:1 mapping to all usable memory. @@ -4329,25 +4404,34 @@ static struct iommu_device *intel_iommu_probe_devic= e(struct device *dev) } =20 dev_iommu_priv_set(dev, info); + ret =3D device_rbtree_insert(iommu, info); + if (ret) + goto free; =20 if (sm_supported(iommu) && !dev_is_real_dma_subdevice(dev)) { ret =3D intel_pasid_alloc_table(dev); if (ret) { dev_err(dev, "PASID table allocation failed\n"); - kfree(info); - return ERR_PTR(ret); + goto clear_rbtree; } } =20 intel_iommu_debugfs_create_dev(info); =20 return &iommu->iommu; +clear_rbtree: + device_rbtree_remove(info); +free: + kfree(info); + + return ERR_PTR(ret); } =20 static void intel_iommu_release_device(struct device *dev) { struct device_domain_info *info =3D dev_iommu_priv_get(dev); =20 + device_rbtree_remove(info); dmar_remove_one_dev_info(dev); intel_pasid_free_table(dev); intel_iommu_debugfs_remove_dev(info); --=20 2.34.1 From nobody Sat Feb 7 16:00:06 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B61BA5A4FF for ; Tue, 20 Feb 2024 07:05:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708412745; cv=none; b=VEbTTQOcNHo+t2+jOdpr7scIpAfRkPP25WLkTU6lWhaxMoAis7Q3orJUSStTkkVrT16FFxivpbG6d0HxAvwKlVxYmze9GcBFcHxe1hRCX/GkbiznBFislG+/ikIZHE3fCvnYtnVekOOC4KsNTfYuMhBrPHdw7dBmtFaKgM61RYI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708412745; c=relaxed/simple; bh=ZbpO3w8GfTzpY3DoVWRz5vgwWK+8/2qXMylcU+ZyyLY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Tbx++h9YifgpE4EJ0ShIh5ojJQS3hQrBJNNICKxuULnPVDIo74iZ66QRFsLylVfKtw2VIFezrAMq5tgSMrvnwqAEEESm+yTdH5f2BQ0/3oGQajEmigQGWNI/ah+Y4pCFiIjAHEMtMM6W++2FTHyDxWTn6k5lOqY8uIW+UtSv9dc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=cTelXNx0; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="cTelXNx0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1708412744; x=1739948744; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ZbpO3w8GfTzpY3DoVWRz5vgwWK+8/2qXMylcU+ZyyLY=; b=cTelXNx0pU6V7a6X/ZLhg2wAq8U9kfkQcqODPPpLLOk9rjp9/RGKme1B IF+KFbBsGhfpwq4Y5ZBh9S+xvw5fIpeO0CNxR8G+uqxskHlQQqfxvy697 pI1QLxibfR1Ly3g0aTZbxpX95q0kxwJeadU60loJ5McIj86Cto3lM52z3 6W9RvtclccF5IIFpazgnzJMw+b0nkQBxjaHKEaTwG2M9RpZioBj8CeuVB 4EFHlsiGo4k8aePPjF5Be7Gk8jXDqDx2qWEq3OnUOdUCrxso1TETGbHw9 Fjn3WfBZPstmH6WLj1NEtppggq+oCS1CgmNx8LrbwSuQgjg6glYID2nSM w==; X-IronPort-AV: E=McAfee;i="6600,9927,10989"; a="2366578" X-IronPort-AV: E=Sophos;i="6.06,172,1705392000"; d="scan'208";a="2366578" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2024 23:05:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,172,1705392000"; d="scan'208";a="4683784" Received: from allen-box.sh.intel.com ([10.239.159.127]) by fmviesa010.fm.intel.com with ESMTP; 19 Feb 2024 23:05:40 -0800 From: Lu Baolu To: Joerg Roedel , Will Deacon , Robin Murphy , Jason Gunthorpe , Kevin Tian Cc: Huang Jiaqing , Ethan Zhao , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Lu Baolu Subject: [PATCH v2 2/2] iommu/vt-d: Use device rbtree in iopf reporting path Date: Tue, 20 Feb 2024 14:59:39 +0800 Message-Id: <20240220065939.121116-3-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240220065939.121116-1-baolu.lu@linux.intel.com> References: <20240220065939.121116-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The existing I/O page fault handler currently locates the PCI device by calling pci_get_domain_bus_and_slot(). This function searches the list of all PCI devices until the desired device is found. To improve lookup efficiency, replace it with device_rbtree_find() to search the device within the probed device rbtree. The I/O page fault is initiated by the device, which does not have any synchronization mechanism with the software to ensure that the device stays in the probed device tree. Theoretically, a device could be released by the IOMMU subsystem after device_rbtree_find() and before iopf_get_dev_fault_param(), which would cause a use-after-free problem. Add a mutex to synchronize the I/O page fault reporting path and the IOMMU release device path. This lock doesn't introduce any performance overhead, as the conflict between I/O page fault reporting and device releasing is very rare. Signed-off-by: Lu Baolu Reviewed-by: Jason Gunthorpe --- drivers/iommu/intel/iommu.h | 2 ++ drivers/iommu/intel/dmar.c | 1 + drivers/iommu/intel/iommu.c | 3 +++ drivers/iommu/intel/svm.c | 17 +++++++++-------- 4 files changed, 15 insertions(+), 8 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 2b67ad0d6fe9..404d2476a877 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -719,6 +719,8 @@ struct intel_iommu { #endif struct iopf_queue *iopf_queue; unsigned char iopfq_name[16]; + /* Synchronization between fault report and iommu device release. */ + struct mutex iopf_lock; struct q_inval *qi; /* Queued invalidation info */ u32 iommu_state[MAX_SR_DMAR_REGS]; /* Store iommu states between suspend = and resume.*/ =20 diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index f9b63c2875f7..d14797aabb7a 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -1097,6 +1097,7 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd) iommu->segment =3D drhd->segment; iommu->device_rbtree =3D RB_ROOT; spin_lock_init(&iommu->device_rbtree_lock); + mutex_init(&iommu->iopf_lock); iommu->node =3D NUMA_NO_NODE; =20 ver =3D readl(iommu->reg + DMAR_VER_REG); diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index acfe27bd3448..6743fe6c7a36 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -4430,8 +4430,11 @@ static struct iommu_device *intel_iommu_probe_device= (struct device *dev) static void intel_iommu_release_device(struct device *dev) { struct device_domain_info *info =3D dev_iommu_priv_get(dev); + struct intel_iommu *iommu =3D info->iommu; =20 + mutex_lock(&iommu->iopf_lock); device_rbtree_remove(info); + mutex_unlock(&iommu->iopf_lock); dmar_remove_one_dev_info(dev); intel_pasid_free_table(dev); intel_iommu_debugfs_remove_dev(info); diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c index b644d57da841..dda276e28325 100644 --- a/drivers/iommu/intel/svm.c +++ b/drivers/iommu/intel/svm.c @@ -645,7 +645,7 @@ static irqreturn_t prq_event_thread(int irq, void *d) struct intel_iommu *iommu =3D d; struct page_req_dsc *req; int head, tail, handled; - struct pci_dev *pdev; + struct device *dev; u64 address; =20 /* @@ -691,21 +691,22 @@ static irqreturn_t prq_event_thread(int irq, void *d) if (unlikely(req->lpig && !req->rd_req && !req->wr_req)) goto prq_advance; =20 - pdev =3D pci_get_domain_bus_and_slot(iommu->segment, - PCI_BUS_NUM(req->rid), - req->rid & 0xff); /* * If prq is to be handled outside iommu driver via receiver of * the fault notifiers, we skip the page response here. */ - if (!pdev) + mutex_lock(&iommu->iopf_lock); + dev =3D device_rbtree_find(iommu, req->rid); + if (!dev) { + mutex_unlock(&iommu->iopf_lock); goto bad_req; + } =20 - intel_svm_prq_report(iommu, &pdev->dev, req); - trace_prq_report(iommu, &pdev->dev, req->qw_0, req->qw_1, + intel_svm_prq_report(iommu, dev, req); + trace_prq_report(iommu, dev, req->qw_0, req->qw_1, req->priv_data[0], req->priv_data[1], iommu->prq_seq_number++); - pci_dev_put(pdev); + mutex_unlock(&iommu->iopf_lock); prq_advance: head =3D (head + sizeof(*req)) & PRQ_RING_MASK; } --=20 2.34.1