From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 8EEAA445AE3 for ; Tue, 4 Aug 2026 23:54:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887667; cv=none; b=RCBfUZjWGbytp2a7AE5B6SJI8VjcDOLrOMDU+4y9hKZWAFefmuofgmq6kPRprcenalUx++0bTxAHdt7woI56PlCx2d+g8K/44qeVegTg6Qs4SOvljA/jB0vBHgDox/ta4vcsO8TJIzQymgFkcr65ZPDGV4vdYWqQUyjoPoBeVSI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887667; c=relaxed/simple; bh=fSdEyytzPOzQz2lGc2NNfCDE0HdpxFXJSWsj0N4NZno=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mjljPqNl4RzgjOafAl2zyN/KHwKth3y58QDA1AZ4Vd9AAR0Kmi9tHGYz+7zcKSV2SYJaIU02nR8HUPGiGT2xpY9YhFjvc5mnoVNy3puOw9adpMJ73v0S8tcoiMER7vZqk2XTTQRsVovPR+JfzuBBlksMO8V4/Jnq88zc5CmVkMM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=W/dJibT8; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="W/dJibT8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887666; x=1817423666; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=fSdEyytzPOzQz2lGc2NNfCDE0HdpxFXJSWsj0N4NZno=; b=W/dJibT8uoQz6glVFyHntcAv6eVA/58Hkkw5XtIHlNwiGtEFPUYJ7NYJ 0vBKk1bLPBtoJitKO75NYvco2n0zmtGkL/8Oh61/Zb1hZh7q3DbJy2V1X Sr2V5CWHvtEtipFXJ2k3ILA8CIoO6N8t3UodMrgp2Pf6nhTuGxucfc/iy baxoy6S2alEUqKdG/zd0tXZcmHIyg0VaHhDrpojfxvwRkXmMCctWoae/X HyS3ZZtjRlljA2uP/ac8FOENjKMvK5JC5uRnyAaeGz8Ad5hFWdoPFPUER NbXSBzXRcecN2vmTcCDV8pNzXak+0/rmsiRdx/VaqMSVHtfx0oxjKcA/Y Q==; X-CSE-ConnectionGUID: PlntM4isTEiSdAUVN7hDwg== X-CSE-MsgGUID: N2N1CY8yQ+K21NBwBxwpcQ== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263178" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263178" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:26 -0700 X-CSE-ConnectionGUID: DpJFnba4Qei3JSO2/c+/0Q== X-CSE-MsgGUID: M8WZ2GYvS+CP3wcQh0zMRw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324292" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:23 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 01/19] iommu/vt-d: Fix UCTP context table slot when copying root entries Date: Wed, 5 Aug 2026 07:42:55 +0800 Message-ID: <20260804234314.3087110-2-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Desnes Nunes When translation is already enabled at boot (e.g. kdump), the vt-d driver copies context tables from the previous kernel's root table. In scalable mode, buses that only populate the upper root half (UCTP, devfn >=3D 0x80) should be written to ctxt_tbls[tbl_idx + 1] through copy_context_table(). However, the current copy path always uses tbl[tbl_idx + 0] in this situa- tion. Since idx wraps to 0 at devfn 0x80 due to a zeroed LCTP, new_ce for LCTP will be NULL and keep pos equals to 0. Thus, UCTP entries will be co- pied into tbl[tbl_idx + 0] instead of tbl[tbl_idx + 1], and written after- wards to root_entry[bus].lo instead of .hi in copy_translation_tables(). In short, devices on bus 0x80 with devfn >=3D 0x80 fail DMA with fault 0x39, which will break drivers running in kernels with translation pre-enabled. This fixes NO_PASID DMAR faults for UCTP-only buses such as: DMAR: [DMA Read NO_PASID] Request device [80:14.0] fault addr 0xe81759000 [fault reason 0x39] SM: Present bit in Root Entry is clear For instance, this fault yielded to locking issues between systemd and xHCI, blocking a system's reboot after a vmcore was captured with kdump: systemd-udevd[246]: usb3: Worker [255] processing SEQNUM=3D2193 is taking = a long time dracut-initqueue[277]: Timed out while waiting for udev queue to empty. systemd-udevd[246]: usb3: Worker [255] processing SEQNUM=3D2193 killed systemd-udevd[246]: usb3: Worker [255] terminated by signal 9 (KILL). ... kdump[569]: saving vmcore complete ... systemd-shutdown[1]: Rebooting. INFO: task kworker/0:1:11 blocked for more than 122 seconds. Not tainted 7.0.0-clean #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/0:1 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x420816= 0 flags:0x00080000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0x299/0x5c0 schedule+0x27/0x80 schedule_timeout+0xbd/0x100 __wait_for_common+0x97/0x1b0 ? __pfx_schedule_timeout+0x10/0x10 xhci_alloc_dev+0x9e/0x2b0 usb_alloc_dev+0x7a/0x3b0 hub_port_connect+0x285/0x960 hub_port_connect_change+0x94/0x290 port_event+0x4bb/0x840 hub_event+0x141/0x460 process_one_work+0x196/0x390 worker_thread+0x1af/0x320 ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 INFO: task systemd-shutdow:1 blocked for more than 122 seconds. Not tainted 7.0.0-clean #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:systemd-shutdow state:D stack:0 pid:1 tgid:1 ppid:0 task_flags:0x4001= 00 flags:0x00080000 Call Trace: __schedule+0x299/0x5c0 schedule+0x27/0x80 schedule_preempt_disabled+0x15/0x30 __mutex_lock.constprop.0+0x547/0xac0 device_shutdown+0xac/0x1b0 kernel_restart+0x3a/0x70 __do_sys_reboot+0x147/0x240 do_syscall_64+0x11b/0x6a0 ? handle_mm_fault+0x110/0x350 ? do_user_addr_fault+0x206/0x680 ? irqentry_exit+0x7a/0x4d0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fe2958da917 RSP: 002b:00007ffc5c458618 EFLAGS: 00000206 ORIG_RAX: 00000000000000a9 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe2958da917 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007ffc5c458790 R08: 0000000000000069 R09: 00000000ffffffff R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000 R13: 0000000000000000 R14: 00007ffc5c4588b8 R15: 0000000000000000 INFO: task systemd-shutdow:1 is blocked on a mutex likely owned by task kw= orker/0:1:11. Fixes: 091d42e43d21 ("iommu/vt-d: Copy translation tables from old kernel") Signed-off-by: Desnes Nunes Tested-by: Tao Liu Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 849d06dfe1ae..cf5f92619943 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1446,7 +1446,7 @@ static int copy_context_table(struct intel_iommu *iom= mu, struct context_entry **tbl, int bus, bool ext) { - int tbl_idx, pos =3D 0, idx, devfn, ret =3D 0, did; + int tbl_idx, tbl_slot =3D 0, idx, devfn, ret =3D 0, did; struct context_entry *new_ce =3D NULL, ce; struct context_entry *old_ce =3D NULL; struct root_entry re; @@ -1462,10 +1462,9 @@ static int copy_context_table(struct intel_iommu *io= mmu, if (idx =3D=3D 0) { /* First save what we may have and clean up */ if (new_ce) { - tbl[tbl_idx] =3D new_ce; + tbl[tbl_idx + tbl_slot] =3D new_ce; __iommu_flush_cache(iommu, new_ce, VTD_PAGE_SIZE); - pos =3D 1; } =20 if (old_ce) @@ -1487,6 +1486,9 @@ static int copy_context_table(struct intel_iommu *iom= mu, } } =20 + /* Track if saving UCTP or LCTP entries in scalable mode */ + tbl_slot =3D ext && devfn >=3D 0x80 ? 1 : 0; + ret =3D -ENOMEM; old_ce =3D memremap(old_ce_phys, PAGE_SIZE, MEMREMAP_WB); @@ -1515,7 +1517,7 @@ static int copy_context_table(struct intel_iommu *iom= mu, new_ce[idx] =3D ce; } =20 - tbl[tbl_idx + pos] =3D new_ce; + tbl[tbl_idx + tbl_slot] =3D new_ce; =20 __iommu_flush_cache(iommu, new_ce, VTD_PAGE_SIZE); =20 --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 D1B64448381 for ; Tue, 4 Aug 2026 23:54:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887669; cv=none; b=o3SHlQJbLLE9R3OSacI5z+cvQ9fmOGZe1IoBHpzkKC5x5R2H4hm0yCDihWstnOcY4J5rPqHLRk0fT8GkneOZNMRCKhgXHfCziDrr0Xz13GDB/6LSi9BOjgAzHgd53L3jdD5vog6diaJZpTO6U+ZWtAZNglLbPGzRDfAV/cPfgA0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887669; c=relaxed/simple; bh=NzOh9HpnXu8dPA60cF2rU7FEPlZpigtx/FS96NI3DkY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DlMMgUMXgYuxAtRtVw9aeNpO2HEq7e4z9LBBu7Vpu5YDNtKvz8i8XYXr1Vy7/iWVNaiZUglNie0381xKG7l82gBuFqb0KNly61VNfwYimOB4rNCn2OPv5SD3XBhmfuOAjB7cVGRJskMu88CAEIl7LekhRFTJmbBxDUk5WlaWaDM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=eu8MjeK2; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="eu8MjeK2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887668; x=1817423668; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=NzOh9HpnXu8dPA60cF2rU7FEPlZpigtx/FS96NI3DkY=; b=eu8MjeK2VQ2V7MGU9XSKvfCi+asFOTC+b5TzOyqevWn0LsPQPoCyS0x6 M6b1pDrfHtQ0hfErvVhhESUzHuV3YUIw1i3GRcxebnXB65EYBFLWR/X0M +oaUGa22iUv5zXYRZtZ82A47olyTDbC0Z7rxbiMdWp9MsjCm130zXAnMk uOGCnfD5VWo3Kiku6p4xwi6VBYRv6aiwpMIMOi5RKhKJsPKP3fn2A1rnt gttvxsbPjbJCqvlD3arxVxXbOvsMI2Kx3j5b1K2EQk1Xn302FLYnYmFQo 0x787rFxDNP3BzsrTw5HKJnlYf4U9baoNmVH1ihFuyfqDYDRF0sfQYfLE Q==; X-CSE-ConnectionGUID: Q15TWpNkRwyZK6vu+WNi0Q== X-CSE-MsgGUID: 2duWkraBR5CCRdrV201Lpg== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263195" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263195" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:28 -0700 X-CSE-ConnectionGUID: AQ2MSFamQBOpDf3klcXw7A== X-CSE-MsgGUID: PvbqMMPHSl+v5+5AoXXaaA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324308" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:25 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 02/19] iommu/vt-d: Use logical OR operator for privilege mode check Date: Wed, 5 Aug 2026 07:42:56 +0800 Message-ID: <20260804234314.3087110-3-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Li RongQing Replace bitwise OR (|) with logical OR (||) in the privilege mode validation check. While both operators produce the same result for boolean values (0 or 1), using logical OR is semantically correct and makes the intent clearer. No functional change, but improves code readability. Signed-off-by: Li RongQing Signed-off-by: Lu Baolu --- drivers/iommu/intel/prq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel/prq.c b/drivers/iommu/intel/prq.c index 586055e51bb2..dddd3b51b657 100644 --- a/drivers/iommu/intel/prq.c +++ b/drivers/iommu/intel/prq.c @@ -223,7 +223,7 @@ static irqreturn_t prq_event_thread(int irq, void *d) goto prq_advance; } =20 - if (unlikely(req->pm_req && (req->rd_req | req->wr_req))) { + if (unlikely(req->pm_req && (req->rd_req || req->wr_req))) { pr_err("IOMMU: %s: Page request in Privilege Mode\n", iommu->name); goto bad_req; --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 6A334446853 for ; Tue, 4 Aug 2026 23:54:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887672; cv=none; b=t3ejjgE2WsyviusunkyJm/rg0v8BtmRRHhJJFmyiVDgq4gz6qFCyXmvGbQoY6uHhPp8y2xuMAMEekViFYUyud4+MoZRvHlOK0DmpvE4WCQ1R4DioJbrGM6AyJUppSFoyeVfPvnPHmJlJ/3oIZbOmSKXPELXNKSqqEgoe8PNgPX4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887672; c=relaxed/simple; bh=sC0Psn9+T0aC5GxdGeCxklvUUEZ395pym97oWYEJoOM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=in8j+VKjxdQsThnzAhKkYdX6+F3cl5tE3iWMTDZmQMCfKhzVD5Dj5JIM1iFcMHRYjLH9cd5oSvNFXNOM3c2899X63KUtG961P40DqjYgKEcqPKhiof7fgNYe+F0aVTpfzyz8wwdreOMqR2sqnYd/GERsMYAUBaxlDP9qCNwrpCE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=HUvnf8th; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="HUvnf8th" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887671; x=1817423671; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=sC0Psn9+T0aC5GxdGeCxklvUUEZ395pym97oWYEJoOM=; b=HUvnf8thyrF+exWNyttE5FAsj1pen+4B9muf7kZMBAH+OaEUbL49Jdf5 nHaJ5zv91dDmFP9l5j/FnDEyxwzB000yf3q30YvFFnXmPcl5Sd+dMX4Yv gYXoetfKuG9UCJ6cCi1VO+caD9esaFf+l3q/fUrcVBxRs7+EoskhkYJwu 8N96ukcjyPwWw/JCD/Eb6ymetuzcnRLMCeVP83wVQij0VNqouwJwLMylG 0h0TZjH8ChltZFR3ilS0kH4IxGEq2E9yJ0AIjvw9xdPeuJ8MoY9XCWgag 6KvV7FR+Jp9FptMay2NjajjwSSyA2HU9moIfsTIrjBmlElMl9hDgDveeL g==; X-CSE-ConnectionGUID: RITrpPOzT8mGHbUvoxyNZA== X-CSE-MsgGUID: kVOaHAPyQKS4oCOU2yFb1w== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263211" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263211" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:30 -0700 X-CSE-ConnectionGUID: BPeWgJm/SMWcLZtekETYcQ== X-CSE-MsgGUID: ONHNiWFMS2uPP3bA/0+hIA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324319" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:28 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 03/19] iommu/vt-d: Fix CACHE_TAG_NESTING_DEVTLB polluting shared variables in flush loop Date: Wed, 5 Aug 2026 07:42:57 +0800 Message-ID: <20260804234314.3087110-4-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Guanghui Feng In cache_tag_flush_range(), the CACHE_TAG_NESTING_DEVTLB case modifies the shared local variables 'addr' and 'mask' before falling through to CACHE_TAG_DEVTLB. This causes all subsequent CACHE_TAG_DEVTLB entries in the same loop iteration to incorrectly use the full-range flush parameters (addr=3D0, mask=3DMAX_AGAW_PFN_WIDTH) instead of the precisely calculated P= SI range. This is not the intended behavior, as regular DEVTLB entries should always perform targeted range-based invalidation. Fix this by having CACHE_TAG_NESTING_DEVTLB directly call cache_tag_flush_devtlb_psi() with the full-range constants and break, instead of modifying shared variables and falling through. This ensures CACHE_TAG_DEVTLB always uses the original calculated addr and mask for precise range flush. This change slightly affects trace_cache_tag_flush_range() behavior. Previously, after addr/mask were overwritten, the tracepoint could record a full-range flush even when the caller requested a narrower range. The tracepoint should reflect caller intent. Although this helper may widen the actual hardware invalidation range for implementation reasons, that does not change what the caller requested, so logging the requested range is the correct behavior. If the actual invalidation range sent to hardware is needed, it is already visible via the qi_submit trace event, which records the invalidation descriptors emitted by the driver. Signed-off-by: Guanghui Feng Signed-off-by: Guixin Liu Signed-off-by: Lu Baolu --- drivers/iommu/intel/cache.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel/cache.c b/drivers/iommu/intel/cache.c index fdc88817709f..26a758b0f501 100644 --- a/drivers/iommu/intel/cache.c +++ b/drivers/iommu/intel/cache.c @@ -454,9 +454,8 @@ void cache_tag_flush_range(struct dmar_domain *domain, = unsigned long start, * affected by a change in S2. So just flush the entire * device cache. */ - addr =3D 0; - mask =3D MAX_AGAW_PFN_WIDTH; - fallthrough; + cache_tag_flush_devtlb_psi(domain, tag, 0, MAX_AGAW_PFN_WIDTH); + break; case CACHE_TAG_DEVTLB: cache_tag_flush_devtlb_psi(domain, tag, addr, mask); break; --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 686E344AB66 for ; Tue, 4 Aug 2026 23:54:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887675; cv=none; b=p/RinaPu7g1xaS0HdjXvQFyzuy6rV2PtxbT8VxfYwXgycCbtetnehYioq57DWuqG6MBXUMrqDHLKK7+wM/007tqjHl4hbpSdYf/ZNlOw88cGasf2E9Yy4iMG+S2D3fFwS0EPF7MzZNCkfIuSNUoZa9jTz1/b39uh/tYVrdkINP0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887675; c=relaxed/simple; bh=wvs5/3Vc8ATiENqbwg9FKEU2eKqwenz/FQk2i2ewikk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=m2vD1W3+byYhavwhpxg9Pm42Q68ng/amOX0tRgpqJPl19jH/aTcW0A7NQfV+rJCPtyqK9JKCSiEzbPv9/uPHaowhWiz1vp/Ea5tWrzQRzKP7pOLZDTI1Af24xdSBrdZ6gVnEnW6bVR89tzXhuoaH3UF3RBIopJ7nkpL4aBGxjQ8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=e/wUSe9H; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="e/wUSe9H" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887673; x=1817423673; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=wvs5/3Vc8ATiENqbwg9FKEU2eKqwenz/FQk2i2ewikk=; b=e/wUSe9HiV+DLPYqnunMgodpkfRnhfawuGHjE/zV0H/F+vDxNVaImBIm f5waLkiL8Cp2qGnys2kUF3Xe719dGZmreyQlbIu8Z8wPmrgZ5Y8CNr6gM ojtx7cCrYcSs7eh24BAFqYqqxmvFvvyvLJ9boCNpWMvL7M3wAn2tnlAQ5 LHFZrVptwGxGSIPkRxXrWHefqfORZdnGVAu1z1k1vjFuSDOgEiDdOqPaf 6iHPYa2ctDh5YcuCdSrYfmr4lv5/AKrwALQTOJ6RzNR8AHZE58mrBbwM+ rxsbpOInwPTLaMZROEzb1dYzpCAeHFv6/rYQRqCmiVKpyhehrltr7AD3B w==; X-CSE-ConnectionGUID: ac98WnNJRi2z/SSoMpsZWQ== X-CSE-MsgGUID: sajR+I/kSiaKRSyBVHaYWw== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263219" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263219" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:32 -0700 X-CSE-ConnectionGUID: rE9v6iQqTuu/ww1Z+8UMKA== X-CSE-MsgGUID: ZeV1DN5CQsmYMzngrZjmBA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324328" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:30 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 04/19] iommu/vt-d: Use kstrtoint_from_user() in dmar_perf_latency_write() Date: Wed, 5 Aug 2026 07:42:58 +0800 Message-ID: <20260804234314.3087110-5-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Dmitry Antipov Simplify 'dmar_perf_latency_write()' by using the convenient 'kstrtoint_from_user()'. Signed-off-by: Dmitry Antipov Signed-off-by: Lu Baolu --- drivers/iommu/intel/debugfs.c | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/drivers/iommu/intel/debugfs.c b/drivers/iommu/intel/debugfs.c index 21e4e465ca58..d87408ebb830 100644 --- a/drivers/iommu/intel/debugfs.c +++ b/drivers/iommu/intel/debugfs.c @@ -690,19 +690,11 @@ static ssize_t dmar_perf_latency_write(struct file *f= ilp, { struct dmar_drhd_unit *drhd; struct intel_iommu *iommu; - int counting; - char buf[64]; + int ret, counting; =20 - if (cnt > 63) - cnt =3D 63; - - if (copy_from_user(&buf, ubuf, cnt)) - return -EFAULT; - - buf[cnt] =3D 0; - - if (kstrtoint(buf, 0, &counting)) - return -EINVAL; + ret =3D kstrtoint_from_user(ubuf, cnt, 0, &counting); + if (ret) + return ret; =20 switch (counting) { case 0: --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 18B2D443E3E for ; Tue, 4 Aug 2026 23:54:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887676; cv=none; b=HecnNKuP6/CRT/NFhgH2oxpPk4fi2ZqQH6pUhzlz4GXuOYfIl2yozt/c9DFnefCOfQua7Yy63jO0K/74kfa2oYM8nPDoRwJ/MwlhYO0N3DODigQ+IvxTf+LzF+ye1q5KkduwYYM9uzIkb7GS8qmYY51nFquvUgf8yFjgsJyFQJ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887676; c=relaxed/simple; bh=YDlwD9/B7SoUh5Cw/Q8HBWUAKwRQP4CubhpluDGbVfg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=C/0mwFZsPUBB58XuLwdRs82aW2YSUULhY0y8Umev9z6hVATyUXflp7iAcSrNl+GUkI7Ssc+tnF5xLARmCaJ5PvRMhc390HEgFhDW2GFeuf6qfR/iu/8A8dNHsCTBPbqDpAS5velk/phSgdbDXEOq1QjW/tQQOeH1+qJ/mBH3ip4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=IbNVlSci; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="IbNVlSci" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887675; x=1817423675; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=YDlwD9/B7SoUh5Cw/Q8HBWUAKwRQP4CubhpluDGbVfg=; b=IbNVlSciVQdwUm0M9/7h+NpFJQB7C/7D3lmw8jNJqeWygc4baySiM4ec mEVIhCx7dFBvT1Apr966r6xgpiet7MsF97lkjQeROa3hddnCGgQQGaDHj Xvg2BEigWJzAQ8I7VgMxnXf4bH+JOh2WWhysoT/1KKDZGzl8JgU3ZsT50 PRKzb9bRjfQKgqb4/PcwqqSgvJFU0mK1lEcrINTYB+/QJTvVZkjOuWxW9 7fXNOF9CM+X9P1HFaj8xEdi5AoJCJVKCtvzUmngIlkv1I5bbTnPyybzYH JfBgUKPJD2uCjOYyz4cGH978utbfJkC+zE0lA/WxrBs4T6GG9j7SEgsW5 w==; X-CSE-ConnectionGUID: lMB2kQzKT6yOCdM1hbW5gQ== X-CSE-MsgGUID: pzFD1IfhR+qPuA/QKPwFYA== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263229" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263229" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:35 -0700 X-CSE-ConnectionGUID: iMEDTU4ORkWONeuykAp4ww== X-CSE-MsgGUID: VgDoMu1TT4K9t+jCdoFRdA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324335" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:32 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 05/19] iommu/vt-d: Fix no_iommu to disable platform opt-in Date: Wed, 5 Aug 2026 07:42:59 +0800 Message-ID: <20260804234314.3087110-6-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Kevin Tian If user explicitly requests to disable iommu (via "iommu=3Doff" or "intel_iommu=3Doff"), there is no reason to force enabling it due to platform opt-in (for external-facing devices). User should be aware of any security implication of doing so. "intel_iommu=3Doff" implements this policy by setting no_platform_optin to skip platform opt-in in platform_optin_force_iommu(). However, "iommu=3Doff" (no_iommu=3D1) doesn't set no_platform_optin hence is broken in this aspect: - detect_intel_iommu() doesn't request ACS if no_iommu=3D1 - platform_optin_force_iommu() forces iommu on if external-facing devices exist and no_platform_optin is not set This leads to a bad configuration with ACS disabled while DMA remapping is enabled. Instead of setting no_platform_optin (will soon be removed) for no_iommu=3D1, directly check no_iommu in platform_optin_force_iommu(). Fixes: 89a6079df791 ("iommu/vt-d: Force IOMMU on for platform opt in hint") Cc: stable@vger.kernel.org Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index cf5f92619943..1a1f27a51063 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -2484,10 +2484,11 @@ static bool has_external_pci(void) =20 static int __init platform_optin_force_iommu(void) { - if (!dmar_platform_optin() || no_platform_optin || !has_external_pci()) + if (no_iommu || !dmar_platform_optin() || no_platform_optin || + !has_external_pci()) return 0; =20 - if (no_iommu || dmar_disabled) + if (dmar_disabled) pr_info("Intel-IOMMU force enabled due to platform opt in\n"); =20 /* @@ -2498,7 +2499,6 @@ static int __init platform_optin_force_iommu(void) iommu_set_default_passthrough(false); =20 dmar_disabled =3D 0; - no_iommu =3D 0; =20 return 1; } --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 90C9C44E66C for ; Tue, 4 Aug 2026 23:54:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887679; cv=none; b=muUE+XZ8hd/79kwDHe4wohERoFz2CDdC0iCTJ+ZCXxzXSoFwAF0xFuDVXpDrldoG5P+iyFOIBgHy7Jcsos5sfv5URqNyVvGnPwnOf+/4GsCI6NfRiVUbvl4EktmiKF0CxiV4L3X5xuKoS32ktutwvTAlC1hkG2+NH3GrjZEO+Fs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887679; c=relaxed/simple; bh=RHtZyNIndU8qQJD0heWZbkAT4r7eUBHP8fHD/4aUctk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hoPZIr3d7tX5K78SLam95ziL8rYE3OQK3f6pvKGeQYDFB7kWZAzf7nHyhQk3WUh4wponY103uHao0Jb+2iz3ayB2M79WVgZ+HF95qfAkwcIGlcdYVVxdsi9d6flQqJg5sLAreQYhuw+s3q7DXurA17KogfiRvtQkAJtyqbY/0ZY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=RmbX0WLs; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="RmbX0WLs" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887678; x=1817423678; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=RHtZyNIndU8qQJD0heWZbkAT4r7eUBHP8fHD/4aUctk=; b=RmbX0WLsBcgjF1V8HgYsDPPAgpQrYttT9LMbgqSqVB8o9dA8/Xo02iXk VKjDSu7zHFBY6OiW0ZnF9JfmtCmOzqniO+fQrVt+g+cuElqi/JNHAE+U9 NID46YEjG53YcOETFez+2DNhlTyeTzaVsp/QVRAlLnO5STbxT8ec4xJrl atubtnaVLuD8xw7Sh5t6NS8OwoB0DH/BCgiNAbdxAPELn4i4YFR5/u2ja wDl4NQ6WiQVyxbpkwnPUBbKe3Zzo/sSjyUDzq5B2AXYx/7DWJRN2+jK+P ULAyTzzLuMTBI7NAUhD4Gkvh0vhGFe4LDJYh4mrkfskQdnltz051LukRu A==; X-CSE-ConnectionGUID: PPwonWpwR5Cwusv39ae9yw== X-CSE-MsgGUID: zAdxU0K2SniLd+zRUsieow== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263240" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263240" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:37 -0700 X-CSE-ConnectionGUID: U6p2i+/mShu/pe00WoWDGQ== X-CSE-MsgGUID: U/RU7AxpR4u0Sy/suQSTbg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324350" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:35 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 06/19] iommu/vt-d: Force requesting ACS when tboot is enabled Date: Wed, 5 Aug 2026 07:43:00 +0800 Message-ID: <20260804234314.3087110-7-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Kevin Tian Currently the conditions of requesting ACS in detect_intel_iommu() don't include tboot, leading to a possible misconfiguration with ACS disabled (e.g. due to user opts) while iommu is later forced on by tboot_force_iommu(). Fix it by checking tboot in detect_intel_iommu(). Fixes: 5d990b627537 ("PCI: add pci_request_acs") Cc: stable@vger.kernel.org Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.h | 2 ++ drivers/iommu/intel/dmar.c | 15 +++++++++++++-- drivers/iommu/intel/iommu.c | 2 +- 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 775f1c4ae346..2cee36138d6e 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1354,6 +1354,7 @@ static inline bool ecmd_has_pmu_essential(struct inte= l_iommu *iommu) =20 extern int dmar_disabled; extern int intel_iommu_enabled; +extern int intel_iommu_tboot_noforce; #else static inline int iommu_calculate_agaw(struct intel_iommu *iommu) { @@ -1366,6 +1367,7 @@ static inline int iommu_calculate_max_sagaw(struct in= tel_iommu *iommu) #define dmar_disabled (1) #define intel_iommu_enabled (0) #define intel_iommu_sm (0) +#define intel_iommu_tboot_noforce (0) #endif =20 static inline const char *decode_prq_descriptor(char *str, size_t size, diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index 767ec092accd..e32685402f74 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -915,6 +915,18 @@ dmar_validate_one_drhd(struct acpi_dmar_header *entry,= void *arg) return 0; } =20 +static bool dmar_required(void) +{ + /* tboot supersedes any user/platform opt */ + if (!intel_iommu_tboot_noforce && tboot_enabled()) + return true; + + if (!no_iommu && (!dmar_disabled || dmar_platform_optin())) + return true; + + return false; +} + void __init detect_intel_iommu(void) { int ret; @@ -928,8 +940,7 @@ void __init detect_intel_iommu(void) if (!ret) ret =3D dmar_walk_dmar_table((struct acpi_table_dmar *)dmar_tbl, &validate_drhd_cb); - if (!ret && !no_iommu && !iommu_detected && - (!dmar_disabled || dmar_platform_optin())) { + if (!ret && !iommu_detected && dmar_required()) { iommu_detected =3D 1; /* Make sure ACS will be enabled */ pci_request_acs(); diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 1a1f27a51063..4d03d9a517de 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -57,7 +57,7 @@ static int rwbf_quirk; * (used when kernel is launched w/ TXT) */ static int force_on =3D 0; -static int intel_iommu_tboot_noforce; +int intel_iommu_tboot_noforce; static int no_platform_optin; =20 #define ROOT_ENTRY_NR (VTD_PAGE_SIZE/sizeof(struct root_entry)) --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 E5522444712 for ; Tue, 4 Aug 2026 23:54:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887682; cv=none; b=gepO6t02pBya+wvENaNSFf2Q041ImKcr1UF9YB9yL5soqtH2CpWDxwCVFNxoBhLYgPjNFJUQXFqyFhm7ThSZhGcfMZBqkvpaKF1Tsa9ribLahVI8dL+69CbBKpNGTOyU1S4u4S7bptKyCaA9yV2+XN1IsDq5S0ZDJhdevh8vQgo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887682; c=relaxed/simple; bh=Fms6Rbz+/KJEXKC76z5BRIO8rQtmau8kHn5raAO6hWY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GRP3Gr7C+/R5fu2O9yP6hHs6weC+TsH64B3fQ90Rj7vW1Fcdk2t/jHaehmY8tA89VRhURdCRwix7GYft8aVXjQQ3qbnl9JaSGN8wmoD+PfZe9W2Zp165zQDgZqFtIVaPuttbtsew2bW65IgVEtXZNyfn/SnZKFIG/O0jKRZkuNQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Eqegvrpj; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="Eqegvrpj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887680; x=1817423680; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Fms6Rbz+/KJEXKC76z5BRIO8rQtmau8kHn5raAO6hWY=; b=Eqegvrpj76dk/WpWssup5cjjqGTdlbKo9y6Zk/48ZwQqNMwWUWw7IDUJ L6Yir03x3e/A5pi+yPXbEPR0UODzOKVj7WZ9uiPzCXEj2Bs8Y7k/JMm1J G+OdrBmOBgBI1HAJAzykRnQKrhIwNbs78+eQB5WMmmTYArOWNZQ+SwsMj C/YL9ayzPWRRhh8k3uOj+W0mr+okADc+jwmIzAQhYS4tyzb3mroAm4yCu m5bggS3B1eOBjjV+FJucT6tXC2HdDfmMNNgdGH2WQkX2JRCRGNQlclgWz PspM9HHOaxoLY+7VNpQt9WHL4hg+cOz+FwtJHo2FfrzoJZlXhEnKlFA9+ g==; X-CSE-ConnectionGUID: mFRnMSfEQpCm+YKcWHblYA== X-CSE-MsgGUID: AiZjhON9Qz2hlGdYGOgmVg== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263252" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263252" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:39 -0700 X-CSE-ConnectionGUID: z0dG605mQBuDFYVk2cpXSQ== X-CSE-MsgGUID: 9+79yXaeSSGPBiAktxi9JQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324358" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:37 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 07/19] iommu/vt-d: Remove dead code when CONFIG_INTEL_IOMMU is not set Date: Wed, 5 Aug 2026 07:43:01 +0800 Message-ID: <20260804234314.3087110-8-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Kevin Tian Those are leftovers and unreachable now: the entire intel directory is built only when CONFIG_INTEL_IOMMU is set. Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.h | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 2cee36138d6e..785aa3b62055 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1340,7 +1340,6 @@ static inline bool intel_domain_is_ss_paging(struct d= mar_domain *domain) return domain->domain.ops =3D=3D &intel_ss_paging_domain_ops; } =20 -#ifdef CONFIG_INTEL_IOMMU extern int intel_iommu_sm; int iommu_calculate_agaw(struct intel_iommu *iommu); int iommu_calculate_max_sagaw(struct intel_iommu *iommu); @@ -1355,20 +1354,6 @@ static inline bool ecmd_has_pmu_essential(struct int= el_iommu *iommu) extern int dmar_disabled; extern int intel_iommu_enabled; extern int intel_iommu_tboot_noforce; -#else -static inline int iommu_calculate_agaw(struct intel_iommu *iommu) -{ - return 0; -} -static inline int iommu_calculate_max_sagaw(struct intel_iommu *iommu) -{ - return 0; -} -#define dmar_disabled (1) -#define intel_iommu_enabled (0) -#define intel_iommu_sm (0) -#define intel_iommu_tboot_noforce (0) -#endif =20 static inline const char *decode_prq_descriptor(char *str, size_t size, u64 dw0, u64 dw1, u64 dw2, u64 dw3) --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 F29AD418A46 for ; Tue, 4 Aug 2026 23:54:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887683; cv=none; b=o0uIIO/QOu1NU9vs3wgbv1u6bUZhjxkfjx2Mc2VW+rq0pJqM9i1LSGjfvTH6wX7/1GSXpPS3LJrnjuVrRc2C5WCqDlHbWgR2scn/lhmIMOcFT6XvV2Zvvoa+DaNPVx+kwPPbQ92c3hdFjYlPHArM2DDpLfMi0u2K8efnbRcSbiM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887683; c=relaxed/simple; bh=SdZ/l+fYJwUzZGSzWTxaBMIaqf3zUpO7xK8W3xhNzzc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L1IOOTXiW6QqgwOZQ0Ky0gANqAVF8NF1MofcsFUlnHRUzU+vRIOODe/oA3Fqt26PGVWBsbCtCq4wKRDqOX39gi7Yi+G1VwPa1zdZ7VHQOqLdwVfLSzN7KfnTe6eAUqDL4JThP68ASd+98J+J0cNK7wOXbtSxmCYpm5Zw4jwUf74= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=IeHNPedR; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="IeHNPedR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887682; x=1817423682; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SdZ/l+fYJwUzZGSzWTxaBMIaqf3zUpO7xK8W3xhNzzc=; b=IeHNPedR40DVojAla4NdnyGU749BWGff/LioMk2gQwVf2bkGXaDWriGP fzZINSEyRbPlTtkSyVSy16n0o9LoSPT5tNJIlnX+g8s34hApxsTOOUnQE 0JDiMrkIEek0RnMWAIL1fBnfil5+vEkRzCL54Yu/tOqFLfe2PcNRWs8WU j3jxyzgrvrVIPehw38acv1NU02kyuI9Y8ZBt0TkJDUqX7NC1nHK9i7hyK DFJBpptt9XCCUkOfcYROovFOSulHXjCRyzze4ztAMPr+4I9ldXe4cBn9m mPGIBfEU4+Jf1h8sDx+s3Iua+MsvWMTExZgZ4K9egk9vuS9/d9onXSbFW w==; X-CSE-ConnectionGUID: 3hiY82ahT42i1QNu7U6B/g== X-CSE-MsgGUID: e1K5o4+iQOiPILYVvhpytw== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263262" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263262" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:42 -0700 X-CSE-ConnectionGUID: Pm33gKI3R++ru4XhCpbKiw== X-CSE-MsgGUID: dw1tCIXySpWjwA1Mw1PcXA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324363" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:39 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 08/19] iommu/vt-d: Consolidate dmar policy management and force_on logic Date: Wed, 5 Aug 2026 07:43:02 +0800 Message-ID: <20260804234314.3087110-9-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Kevin Tian Currently the dmar on/off is carried by multiple variables (no_iommu, dmar_disabled, no_platform_optin, etc.) with error-prone force_on logic scattered in multiple places. Unify/centralize the policy/priority management for various force_on scenarios. No functional impact except one case - "intel_iommu=3Doff" sets no_platform_optin which is checked in platform_optin_force_iommu() but not in detect_intel_iommu(), leading to ACS unnecessarily requested when iommu could not be forced on later. Now with the unified logic this becomes more consistent. Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.h | 45 ++++++++++++++++++++++++++++ drivers/iommu/intel/dmar.c | 58 ++++++++++++++++++++++++++++++++++--- drivers/iommu/intel/iommu.c | 7 +++++ 3 files changed, 106 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 785aa3b62055..dd2376a079b9 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1351,6 +1351,51 @@ static inline bool ecmd_has_pmu_essential(struct int= el_iommu *iommu) DMA_ECMD_ECCAP3_ESSENTIAL; } =20 +enum dmar_force_on { + DMAR_FORCEON_PLATFORM, + DMAR_FORCEON_TBOOT +}; + +/* + * On policies are positive, with more positive value being stronger. + * Off policies are negative, with more negative value being stronger. + * + * 'dmar' here refers to DMA remapping instead of the dmar/iommu unit. + * + * - DMAR_FORCE_ON: + * force to turn on (e.g. by tboot or platform opt-in). + * + * - DMAR_ON: + * turn on by build configuration (CONFIG_INTEL_IOMMU_DEFAULT_ON=3Don) + * or user opts ("intel_iommu=3Don"). + * + * - DMAR_DEFAULT_OFF + * turn off by build configuration (CONFIG_INTEL_IOMMU_DEFAULT_ON=3Dof= f). + * + * - DMAR_USER_OFF + * turn off by user opts ("intel_iommu=3Doff" or "iommu=3Doff"). + * + * - '0' is invalid, compared to decide the on/off policy + * + */ +#define DMAR_FORCE_ON 2 +#define DMAR_ON 1 +#define DMAR_DEFAULT_OFF -1 +#define DMAR_USER_OFF -2 +extern int dmar_policy; + +static inline bool dmar_policy_on(void) +{ + return dmar_policy > 0; +} + +static inline bool dmar_policy_off(void) +{ + return dmar_policy < 0; +} + +bool dmar_can_force_on(enum dmar_force_on force_on); + extern int dmar_disabled; extern int intel_iommu_enabled; extern int intel_iommu_tboot_noforce; diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index e32685402f74..bc2f6597eb27 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -915,14 +915,61 @@ dmar_validate_one_drhd(struct acpi_dmar_header *entry= , void *arg) return 0; } =20 +/* + * Centralized helper for deciding the force_on policy + * + * dmar off policies (for DMA Remapping) are defined from stronger + * (more negative values) to weaker (less negative values). + * + * When a force_on type is passed in, it is associated to a reference + * level for comparison. force_on is permitted when dmar is in a + * off policy less negative than the reference level (if the policy is + * on then the check is always true). + * + * For supported force_on types: + * + * - DMAR_FORCEON_TBOOT: tboot strictly requires DMA remapping for secure + * boot hence supersedes any user opts ("iommu=3Doff" or "intel_iommu=3D= off") + * and weaker off policies. + * + * - DMAR_FORCEON_PLATFORM: external-facing devices requires DMA + * remapping to prevent malicious downstream external devices from + * composing DMA attacks. force_on is permitted only if dmar policy is + * off by build configurations (CONFIG_INTEL_IOMMU_DEFAULT_ON=3Doff). + * + * In a nutshell, "trusted boot environment" is considered stronger than + * "user choices", which in turn is stronger than "platform opt-in hint". + */ +bool dmar_can_force_on(enum dmar_force_on force_on) +{ + int level; + + switch (force_on) { + case DMAR_FORCEON_TBOOT: + level =3D DMAR_USER_OFF; + break; + case DMAR_FORCEON_PLATFORM: + level =3D DMAR_DEFAULT_OFF; + break; + default: + level =3D INT_MAX; + pr_warn("Unsupported force_on type (%d)\n", force_on); + break; + } + + return dmar_policy >=3D level; +} + static bool dmar_required(void) { - /* tboot supersedes any user/platform opt */ + if (dmar_policy_on()) + return true; + if (!intel_iommu_tboot_noforce && tboot_enabled()) - return true; + return dmar_can_force_on(DMAR_FORCEON_TBOOT); =20 - if (!no_iommu && (!dmar_disabled || dmar_platform_optin())) - return true; + if (dmar_platform_optin()) + return dmar_can_force_on(DMAR_FORCEON_PLATFORM); =20 return false; } @@ -936,6 +983,9 @@ void __init detect_intel_iommu(void) }; =20 down_write(&dmar_global_lock); + if (no_iommu) + dmar_policy =3D DMAR_USER_OFF; + ret =3D dmar_table_detect(); if (!ret) ret =3D dmar_walk_dmar_table((struct acpi_table_dmar *)dmar_tbl, diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 4d03d9a517de..2f0cd1714923 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -199,6 +199,11 @@ static LIST_HEAD(dmar_satc_units); =20 static void intel_iommu_domain_free(struct iommu_domain *domain); =20 +#ifdef CONFIG_INTEL_IOMMU_DEFAULT_ON +int dmar_policy =3D DMAR_ON; +#else +int dmar_policy =3D DMAR_DEFAULT_OFF; +#endif int dmar_disabled =3D !IS_ENABLED(CONFIG_INTEL_IOMMU_DEFAULT_ON); int intel_iommu_sm =3D IS_ENABLED(CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT= _ON); =20 @@ -240,9 +245,11 @@ static int __init intel_iommu_setup(char *str) =20 while (*str) { if (!strncmp(str, "on", 2)) { + dmar_policy =3D DMAR_ON; dmar_disabled =3D 0; pr_info("IOMMU enabled\n"); } else if (!strncmp(str, "off", 3)) { + dmar_policy =3D DMAR_USER_OFF; dmar_disabled =3D 1; no_platform_optin =3D 1; pr_info("IOMMU disabled\n"); --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 793FD44C669 for ; Tue, 4 Aug 2026 23:54:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887689; cv=none; b=Ef45G+ngiBQ1KKqjSmDwn7aThhC4sP8oaiuZOKY+/8CfphZqmUMFZnFgQ0lXflmUnm0fFXu2HabfMdYdiXkLI1DYmz7m4St1WP4bPZuA69igR+qoQ6SPH0btZyne1r5cJrtJ215dA0wmZpovZpBiwy+2kKPmbV0qxNtsgrlT6f8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887689; c=relaxed/simple; bh=A+gsmRHhQ65EGjIdwCREM1GXzXS4uN/8v+W2J6N27oU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XHAssHckvzX7UiW5qJD0LPaCiSprpIJW941gagUHfLHxOGdi4wLj8Ej4VODpTTsfJ3e6tcWFopILk/N+3WOt7vVbppWaBlzSgJgiTSRTeMVg4dLem8N/Kf38g+z2nHKQ0jKKk9+nkMpQmE1Pq7yTrmNZfyPFj2TbW7LnuM3bi6E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=At17JKp0; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="At17JKp0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887685; x=1817423685; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=A+gsmRHhQ65EGjIdwCREM1GXzXS4uN/8v+W2J6N27oU=; b=At17JKp0nCK/vxEa7j+sb27t78Vl2z8ITRzurYmI0LbbPaGgXSFHuFrS +hZH1TFDyRC1alTx7XyZ7Jrd8lDBhUS4dYkflxFm1bo4xkse3Y/lDWonQ Q8JjzF8hsJXWcpLifDzfzGraux1ogyPPxOP/uXs7WU+IQIKByCtDC7YdL Nj9mpP4ArgkPwPDUGk/7+5MO7roS8CDYZuczPDpz6SbiR5u+pDkLdIkbL vGkn8MDUqiuaL9sLFnp/rk1IPGUlEpYAF1X0DGNlNk9hInPjSfnZXZqpb RwUKtu5qf0VD0M/P0gpv8lO34DIm4EhXfHbCT39GkdMLpt1b7utrrv/Y1 A==; X-CSE-ConnectionGUID: Dj2RVR/XQ7CgIAmOGlvNAw== X-CSE-MsgGUID: kMts59wyTNumRcJpqh0c+Q== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263271" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263271" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:44 -0700 X-CSE-ConnectionGUID: FmMSGh/tSHmi+OWGHO1ExQ== X-CSE-MsgGUID: UDhXmBsaTiKEWd/XRRdzWg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324367" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:42 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 09/19] iommu/vt-d: Use dmar_can_force_on() for platform opt-in Date: Wed, 5 Aug 2026 07:43:03 +0800 Message-ID: <20260804234314.3087110-10-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Kevin Tian So the policy of requesting ACS in detect_intel_iommu() is consistent with that in platform_optin_force_iommu(). While at it, remove no_platform_optin which is unnecessary now. Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 2f0cd1714923..ce0794e82e55 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -58,7 +58,6 @@ static int rwbf_quirk; */ static int force_on =3D 0; int intel_iommu_tboot_noforce; -static int no_platform_optin; =20 #define ROOT_ENTRY_NR (VTD_PAGE_SIZE/sizeof(struct root_entry)) =20 @@ -251,7 +250,6 @@ static int __init intel_iommu_setup(char *str) } else if (!strncmp(str, "off", 3)) { dmar_policy =3D DMAR_USER_OFF; dmar_disabled =3D 1; - no_platform_optin =3D 1; pr_info("IOMMU disabled\n"); } else if (!strncmp(str, "igfx_off", 8)) { disable_igfx_iommu =3D 1; @@ -2491,20 +2489,23 @@ static bool has_external_pci(void) =20 static int __init platform_optin_force_iommu(void) { - if (no_iommu || !dmar_platform_optin() || no_platform_optin || - !has_external_pci()) + if (!dmar_platform_optin() || !dmar_can_force_on(DMAR_FORCEON_PLATFORM)) return 0; =20 - if (dmar_disabled) - pr_info("Intel-IOMMU force enabled due to platform opt in\n"); + if (!has_external_pci()) + return 0; =20 /* * If Intel-IOMMU is disabled by default, we will apply identity * map for all devices except those marked as being untrusted. */ - if (dmar_disabled) + if (dmar_policy_off()) { + pr_info("Intel-IOMMU force enabled due to platform opt in\n"); iommu_set_default_passthrough(false); + } =20 + /* No concurrent access to dmar_policy at this point. */ + dmar_policy =3D DMAR_FORCE_ON; dmar_disabled =3D 0; =20 return 1; --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 B4DD944E645 for ; Tue, 4 Aug 2026 23:54:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887688; cv=none; b=DEQahUBH1BWdAdDS4+c41i6Yc5lLVO+ehAKoO9fTj5rUEhsTFfwgmjpDTx2SZnubEacMKDS3aujPfXZrRp4zaWqrFVYZttE6CDDB3DFfDPkWnfFVWrvTUMN3I+huLKmaTJhdZIAfhdKmKycTw/H8p9Uf8xkAdFl8XJ0olUcF968= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887688; c=relaxed/simple; bh=8FoqMs3ZYEeu3bLuLfkxhhxNSLw1by1xUZ5wqDUZOY4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=amJT2RAoketzHCODo/GViV7Lyt6MDQGDpLwpCtkMWtH2VqbIVNOT8LG8Nsj7Vz5IAumhB57ZsCHIW9A8Ac/5BZB4hb1odv0Ap055Jf3zToOE6u4RPwefdTAqkDWdF7TD7RVC11iqmqD6RQY6erpI3i1Sq2TDxiHd4t7YT8ww0xs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=DSEaoNHe; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="DSEaoNHe" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887687; x=1817423687; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=8FoqMs3ZYEeu3bLuLfkxhhxNSLw1by1xUZ5wqDUZOY4=; b=DSEaoNHel1HaZZa8JzVOdP123hQA+M25M8Tg9HMvWiDMuzFVDl3iEmIC W1ivI5mojiSK6CoWp6v6Qc7utmV49rVqDK4K2PQyIRzgHcG89ZLpqv1ws Rc+xVA2kDaDonzY+jWtmfVmvFY/Ba2lROqdN3izS241nUlfKfmUdMX3W6 qHgJcjmJMQQ3NUT3BZJ6LYB8Hips6QoFc4mQX0PAZtnolOKn3/68li171 Cih1k7WmRELMsvR8UNXG2SchCbE939QuTuu3Cym/IOXHGP+cQ5fT+TdMW gztJgVkSTrCgrh0JDQauZfSd+GXGOMt1FCI91T/Ncd1otKc5zS24EoLCM w==; X-CSE-ConnectionGUID: JhkhhjJcRnqYVgdwz6KgTQ== X-CSE-MsgGUID: WnPyaGp7T3OW7txHpCI8Mw== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263283" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263283" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:46 -0700 X-CSE-ConnectionGUID: 1cqK8tBlTACzvvVmxU3djg== X-CSE-MsgGUID: Z1YrbryETTStT11KKZJVgw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324372" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:44 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 10/19] iommu/vt-d: Call dmar_can_force_on() for tboot opt-in Date: Wed, 5 Aug 2026 07:43:04 +0800 Message-ID: <20260804234314.3087110-11-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Kevin Tian So the policy of requesting ACS in detect_intel_iommu() is consistent with that in tboot_force_iommu(). Though tboot is the strongest override so far, dmar_can_force_on() may return false due to future extensions. In this case panic the kernel, as is already done when failing to initialize DMA remapping for tboot. No functional impact at this point. Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index ce0794e82e55..5eb80aeec274 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -2550,12 +2550,17 @@ static int __init probe_acpi_namespace_devices(void) =20 static __init int tboot_force_iommu(void) { - if (!tboot_enabled()) + if (!tboot_enabled() || intel_iommu_tboot_noforce) return 0; =20 - if (no_iommu || dmar_disabled) + if (!dmar_can_force_on(DMAR_FORCEON_TBOOT)) + panic("tboot: Failed to force IOMMU on\n"); + + if (dmar_policy_off()) pr_warn("Forcing Intel-IOMMU to enabled\n"); =20 + /* No concurrent access to dmar_policy at this point. */ + dmar_policy =3D DMAR_FORCE_ON; dmar_disabled =3D 0; no_iommu =3D 0; =20 @@ -2572,8 +2577,7 @@ int __init intel_iommu_init(void) * Intel IOMMU is required for a TXT/tboot launch or platform * opt in, so enforce that. */ - force_on =3D (!intel_iommu_tboot_noforce && tboot_force_iommu()) || - platform_optin_force_iommu(); + force_on =3D tboot_force_iommu() || platform_optin_force_iommu(); =20 down_write(&dmar_global_lock); if (dmar_table_init()) { --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 EAD35449EAB for ; Tue, 4 Aug 2026 23:54:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887690; cv=none; b=TAA3wlEmydJdX/mONYPbwOxXZeb91LPLuNBSOnxpB25seCwXr/6LOCrTPehfQDTCyhNnXBjinQl2DvvFwWqBM/BdPlcF6PK8hR1yR9g4sF9bGF+sCqk/XcqlZgguhcuBOYT0gQs1yrQiAKR7iEZxEFMdPD6NnMhIgPyyQoL4ZHs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887690; c=relaxed/simple; bh=dlVfOaW2BcS/8ZscA+AC93RlpoSyCVyt3w8eLMCO4GM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HwS+60qIBlnGOxp/9wTU/zuLbEPxD0X8oPgfQEGKcUne4DEHYx7ePU3E9o1sVLhdNAPd7MELgNQ0/sa3SiMWFnlZwG8SkEyP6uoGwFfiuJMpnWX5mdVQ0zL3mlaYw9E2DtYwt2uxbCwRW5e0PhHiXwRHgEyNJ347jPteubBzFBU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=i5SlhXWz; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="i5SlhXWz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887689; x=1817423689; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=dlVfOaW2BcS/8ZscA+AC93RlpoSyCVyt3w8eLMCO4GM=; b=i5SlhXWzIArhTGERGr8t4bL1n10LVc0QhfvaYGmA+5m2aSRnyKIVpyfP sVR9ZA9ve4ldaqckSupZfb3uQ3AdbhxRh2ns/uIGREtvxLBloqRywJDYH PZu++qfA9bHpK33r04xDyuSjIT/MhKJdOdQe2gXHgN4osre+UjjMb7Pvm w5gR3wCRYwCG9U3dhEhgxH+k4TcB4nAzMBmtWSo6S2TUJtP4OxR54UU8l ZVlcKhmd2AfNw7DdW+Foslb72tubF11zNokPQ9ueyEhACkbkDJnIuxEh+ YZ39AFsGAp9iLQeDjvUSI6NIfqx87DiE0zsnYI9Ha87sR1GTL0XmgRnFx A==; X-CSE-ConnectionGUID: ctpgmtYLTZGpLxSlGic1vQ== X-CSE-MsgGUID: le+UDm/LR0axyxTXq0Ah8A== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263297" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263297" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:49 -0700 X-CSE-ConnectionGUID: HrYMlWOQSx27UxwSE41lrQ== X-CSE-MsgGUID: OnuhxYahTmaXjbpymYaLhQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324381" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:46 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 11/19] iommu/vt-d: Remove the 'force_on' variable Date: Wed, 5 Aug 2026 07:43:05 +0800 Message-ID: <20260804234314.3087110-12-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Kevin Tian The force_on variable is now redundant - same information captured by "dmar_policy =3D=3D DMAR_FORCE_ON". Replace all force_on checks with dmar_policy_force_on(). Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.h | 5 +++++ drivers/iommu/intel/iommu.c | 37 +++++++++++++++++-------------------- 2 files changed, 22 insertions(+), 20 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index dd2376a079b9..40da2ed7e254 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1394,6 +1394,11 @@ static inline bool dmar_policy_off(void) return dmar_policy < 0; } =20 +static inline bool dmar_policy_force_on(void) +{ + return dmar_policy =3D=3D DMAR_FORCE_ON; +} + bool dmar_can_force_on(enum dmar_force_on force_on); =20 extern int dmar_disabled; diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 5eb80aeec274..118c62e859fd 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -53,10 +53,9 @@ static int rwbf_quirk; #define rwbf_required(iommu) (rwbf_quirk || cap_rwbf((iommu)->cap)) =20 /* - * set to 1 to panic kernel if can't successfully enable VT-d - * (used when kernel is launched w/ TXT) + * Skip forcing iommu on and avoid tboot-related kernel panics during + * initialization when set to 1 (via intel_iommu=3Dtboot_noforce). */ -static int force_on =3D 0; int intel_iommu_tboot_noforce; =20 #define ROOT_ENTRY_NR (VTD_PAGE_SIZE/sizeof(struct root_entry)) @@ -1713,7 +1712,7 @@ static int __init init_dmars(void) * we always have to disable PMRs or DMA may fail on * this device */ - if (force_on) + if (dmar_policy_force_on()) iommu_disable_protect_mem_regions(iommu); continue; } @@ -1805,7 +1804,7 @@ static int init_iommu_hw(void) * we always have to disable PMRs or DMA may fail on * this device */ - if (force_on) + if (dmar_policy_force_on()) iommu_disable_protect_mem_regions(iommu); continue; } @@ -1866,7 +1865,7 @@ static void iommu_resume(void *data) unsigned long flag; =20 if (init_iommu_hw()) { - if (force_on) + if (dmar_policy_force_on()) panic("tboot: IOMMU setup failed, DMAR can not resume!\n"); else WARN(1, "IOMMU setup failed, DMAR can not resume!\n"); @@ -2134,7 +2133,7 @@ static int intel_iommu_add(struct dmar_drhd_unit *dma= ru) /* * we always have to disable PMRs or DMA may fail on this device */ - if (force_on) + if (dmar_policy_force_on()) iommu_disable_protect_mem_regions(iommu); return 0; } @@ -2487,13 +2486,13 @@ static bool has_external_pci(void) return false; } =20 -static int __init platform_optin_force_iommu(void) +static void __init platform_optin_force_iommu(void) { if (!dmar_platform_optin() || !dmar_can_force_on(DMAR_FORCEON_PLATFORM)) - return 0; + return; =20 if (!has_external_pci()) - return 0; + return; =20 /* * If Intel-IOMMU is disabled by default, we will apply identity @@ -2507,8 +2506,6 @@ static int __init platform_optin_force_iommu(void) /* No concurrent access to dmar_policy at this point. */ dmar_policy =3D DMAR_FORCE_ON; dmar_disabled =3D 0; - - return 1; } =20 static int __init probe_acpi_namespace_devices(void) @@ -2548,10 +2545,10 @@ static int __init probe_acpi_namespace_devices(void) return 0; } =20 -static __init int tboot_force_iommu(void) +static __init void tboot_force_iommu(void) { if (!tboot_enabled() || intel_iommu_tboot_noforce) - return 0; + return; =20 if (!dmar_can_force_on(DMAR_FORCEON_TBOOT)) panic("tboot: Failed to force IOMMU on\n"); @@ -2563,8 +2560,6 @@ static __init int tboot_force_iommu(void) dmar_policy =3D DMAR_FORCE_ON; dmar_disabled =3D 0; no_iommu =3D 0; - - return 1; } =20 int __init intel_iommu_init(void) @@ -2577,17 +2572,19 @@ int __init intel_iommu_init(void) * Intel IOMMU is required for a TXT/tboot launch or platform * opt in, so enforce that. */ - force_on =3D tboot_force_iommu() || platform_optin_force_iommu(); + tboot_force_iommu(); + if (!dmar_policy_force_on()) + platform_optin_force_iommu(); =20 down_write(&dmar_global_lock); if (dmar_table_init()) { - if (force_on) + if (dmar_policy_force_on()) panic("tboot: Failed to initialize DMAR table\n"); goto out_free_dmar; } =20 if (dmar_dev_scope_init() < 0) { - if (force_on) + if (dmar_policy_force_on()) panic("tboot: Failed to initialize DMAR device scope\n"); goto out_free_dmar; } @@ -2641,7 +2638,7 @@ int __init intel_iommu_init(void) =20 ret =3D init_dmars(); if (ret) { - if (force_on) + if (dmar_policy_force_on()) panic("tboot: Failed to initialize DMARs\n"); pr_err("Initialization failed\n"); goto out_free_dmar; --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 3C56D45041E for ; Tue, 4 Aug 2026 23:54:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887693; cv=none; b=gCp6NSLDQ83NNKVqLYGmVG4dexFSQ8WRGHFnid+O8ILRmQ8upQ4mQ/LPvs2YCkr561BAKUDBlTgSqI7wqzopvnQBUcbvMJQvXCtBbBXjKMFTcPGdOKxvto2PBJKR+TA2UY/Vp1TKRsw4jzxvf2gqS+TtxyWWJoGjwLD0wqXT0jg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887693; c=relaxed/simple; bh=I0opl1w8B2GbMLseY7HCMG0uR/eGIL6O6uLirKXdHBI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nAFFruIE3vSLegF2Uz9+BGBdbgHyy3lpDak0Dg5ULlsQwl56ng6v9xT2aqV6IR0y3e/shwaspNZaCsll5q+6lQH7pepQxQ4isOjE+z5++MdUVfGdLjuVUZpGncRBIiy6RGb7l2+DBh9hnaTBar9lULUaiWry0puRonC7YVdWw60= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Nw8TqYMG; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="Nw8TqYMG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887693; x=1817423693; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=I0opl1w8B2GbMLseY7HCMG0uR/eGIL6O6uLirKXdHBI=; b=Nw8TqYMGhEwTQ5ZlSX4Yd4QEvSV/7H9Ixk7CWWPUY+HIYguEdn87IbA3 b5qHhRygMLx1iPyODT0C29wAbVQlT0miOUB/scVDVXnlWrsd/ArN6oM1r amc5geht9+TRC3bFhnh43ZBJ+lbALxPl665+vyqu1P8iNId+AL4YvXZn8 +wMrmUPfhwvBq+20AMCMj+1E/BQeu5k83UQLpokg0myEBFhOdOqoopoIP JJXMBenk8t9+P8LWvsqnRw2LcYBhHP2m1IFhEvAdew30itMR6STyqbJYt Un/d5t7Y5m48Xs9GJveBY5WC125LgMRoKZh+0MJTgMwmpfl7exDTAf4yn A==; X-CSE-ConnectionGUID: bgk08nglTI+hcOD78IiK7w== X-CSE-MsgGUID: rGAfQJw6RCyu/ZXKRmGqxQ== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263312" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263312" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:52 -0700 X-CSE-ConnectionGUID: 0h6Kcx7BTnaGgJ/fUIUZjg== X-CSE-MsgGUID: uepW04ACT1uF80xOKn1ceA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324388" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:49 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 12/19] iommu/vt-d: Remove dmar_disabled Date: Wed, 5 Aug 2026 07:43:06 +0800 Message-ID: <20260804234314.3087110-13-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Kevin Tian It's replaced by dmar_policy_off() now, covering both "iommu=3Doff" and "intel_iommu=3Doff". Also remove unnecessary checks on no_iommu, leaving only one exception in intel_iommu_init() which skips debugfs init for "iommu=3Doff" but not "intel_iommu=3Doff". Keep it to avoid surprise for now. Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.h | 1 - drivers/iommu/intel/iommu.c | 9 ++------- drivers/iommu/intel/svm.c | 2 +- 3 files changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 40da2ed7e254..9805edb8c7df 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1401,7 +1401,6 @@ static inline bool dmar_policy_force_on(void) =20 bool dmar_can_force_on(enum dmar_force_on force_on); =20 -extern int dmar_disabled; extern int intel_iommu_enabled; extern int intel_iommu_tboot_noforce; =20 diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 118c62e859fd..a996b72aca57 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -202,7 +202,6 @@ int dmar_policy =3D DMAR_ON; #else int dmar_policy =3D DMAR_DEFAULT_OFF; #endif -int dmar_disabled =3D !IS_ENABLED(CONFIG_INTEL_IOMMU_DEFAULT_ON); int intel_iommu_sm =3D IS_ENABLED(CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT= _ON); =20 int intel_iommu_enabled =3D 0; @@ -244,11 +243,9 @@ static int __init intel_iommu_setup(char *str) while (*str) { if (!strncmp(str, "on", 2)) { dmar_policy =3D DMAR_ON; - dmar_disabled =3D 0; pr_info("IOMMU enabled\n"); } else if (!strncmp(str, "off", 3)) { dmar_policy =3D DMAR_USER_OFF; - dmar_disabled =3D 1; pr_info("IOMMU disabled\n"); } else if (!strncmp(str, "igfx_off", 8)) { disable_igfx_iommu =3D 1; @@ -2371,7 +2368,7 @@ void intel_iommu_shutdown(void) struct dmar_drhd_unit *drhd; struct intel_iommu *iommu =3D NULL; =20 - if (no_iommu || dmar_disabled) + if (dmar_policy_off()) return; =20 /* @@ -2505,7 +2502,6 @@ static void __init platform_optin_force_iommu(void) =20 /* No concurrent access to dmar_policy at this point. */ dmar_policy =3D DMAR_FORCE_ON; - dmar_disabled =3D 0; } =20 static int __init probe_acpi_namespace_devices(void) @@ -2558,7 +2554,6 @@ static __init void tboot_force_iommu(void) =20 /* No concurrent access to dmar_policy at this point. */ dmar_policy =3D DMAR_FORCE_ON; - dmar_disabled =3D 0; no_iommu =3D 0; } =20 @@ -2602,7 +2597,7 @@ int __init intel_iommu_init(void) if (!no_iommu) intel_iommu_debugfs_init(); =20 - if (no_iommu || dmar_disabled) { + if (dmar_policy_off()) { /* * We exit the function here to ensure IOMMU's remapping and * mempool aren't setup, which means that the IOMMU's PMRs diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c index 726f7b6d0bff..432e35723ce9 100644 --- a/drivers/iommu/intel/svm.c +++ b/drivers/iommu/intel/svm.c @@ -115,7 +115,7 @@ static int intel_iommu_sva_supported(struct device *dev) struct device_domain_info *info =3D dev_iommu_priv_get(dev); struct intel_iommu *iommu; =20 - if (!info || dmar_disabled) + if (!info || dmar_policy_off()) return -EINVAL; =20 iommu =3D info->iommu; --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 D0735449EAB for ; Tue, 4 Aug 2026 23:54:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887695; cv=none; b=BGAZWRrQ9qaOkqt/imo42ryAnheIPZ/LzdVz4WhaA7gbtrZVC0PSPcueH7whTGY+hghKJ2DK8LPmYZOLMUib//iGVrDkI9YTaODjT9p+Ef3b44P00A7diE90+IOYnYvYGVoaYE55ebyYMxClEq/C4KmxBrsHUZTnzKoWNHfNqQU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887695; c=relaxed/simple; bh=ofazySFC81vyyWifIxKn03mdBwsTstjvWNV/8XW81E4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fbcUWpkrJNJhvYi5W7XOMuXjj+Z+UaVCg50vVXQbwl0w13jx7FUjxU0BlVbu3FixrdauzQg3VNtM5sWJPogbpstRf5oVQ8aeW2o8IL5KcgIpz1F/IaEKnnoVkdYpOwiybJXxlD757UEbVTbAw6b9mdEo4AFQgVaVdQC4XBATYFA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=HdL2YAsR; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="HdL2YAsR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887694; x=1817423694; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ofazySFC81vyyWifIxKn03mdBwsTstjvWNV/8XW81E4=; b=HdL2YAsRJ2I9MIK+blsPNIprk3lLaE6t4emiRTuRKepOahpfWN/DQ6Az 1NPy1p1Yxt0pqZgDXxdOrMi+Igzw3Z4HFndI4R0LnxsFePZTUd61CGIxr nb3BYULSY6kh5dYZfT1jknqC0Wct3upfsjEYBMR1G6S8Mgg1gxxpQXXwo 1JwWv1B7+IvRHmgExmB1mCpSw+hcqJe46SEjm3h0HIqC4XkW5wTrbDuJ+ hINlaUub80ug9LzcISH09CZVMBrarQpwvkRDlrf/zI1cvnEb7/laKOtyi RPtiWUCaZW8yt6Gv5Kj+OzMJK5ZJvUBjTwxpYHEQIGvqoh//BNJT5e2hR g==; X-CSE-ConnectionGUID: SEfJS8C9QV+xs8xRsHG4qQ== X-CSE-MsgGUID: lKg9ieP2QmGJeqvxFRF5PA== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263323" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263323" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:54 -0700 X-CSE-ConnectionGUID: Qk46S+E6R9aOhmH+iUlUGg== X-CSE-MsgGUID: bxNFXR1UT0aSqf6xqa9M/w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324392" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:51 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 13/19] iommu/vt-d: Support the new DMA_REMAP_OPT_OUT flag bit Date: Wed, 5 Aug 2026 07:43:07 +0800 Message-ID: <20260804234314.3087110-14-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: Kevin Tian Some BIOS already provides config options to expose/hide VT-d units as a whole to/from system software. A new demand is to allow exposing VT-d units but requesting system software to disable DMA remapping while sustaining interrupt remapping. This can be communicated now by setting the new DMA_REMAP_OPT_OUT flag bit in the DMAR table, as introduced in VT-d spec v5.2 (section 8.1, DMA Remapping Reporting Structure). Introduce a new off policy (DMAR_FW_OFF) for DMA_REMAP_OPT_OUT. As the strongest off policy, it cannot be overridden by user opts or any force_on types. If tboot is enabled in the meantime, kernel will panic. It is user responsibility to configure BIOS properly. One cleanup is left for future - the DMAR flag is parsed multiple times, in detect_intel_iommu(), dmar_platform_optin() (which can be called at run-time), etc. Caching it is a cleaner way. Signed-off-by: Kevin Tian Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.h | 4 ++++ include/linux/dmar.h | 1 + drivers/iommu/intel/dmar.c | 34 ++++++++++++++++++++++++---------- 3 files changed, 29 insertions(+), 10 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 9805edb8c7df..656cd311ed9a 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1375,6 +1375,9 @@ enum dmar_force_on { * - DMAR_USER_OFF * turn off by user opts ("intel_iommu=3Doff" or "iommu=3Doff"). * + * - DMAR_FW_OFF + * turn off due to firmware opt-out (DMAR_REMAP_OPT_OUT) + * * - '0' is invalid, compared to decide the on/off policy * */ @@ -1382,6 +1385,7 @@ enum dmar_force_on { #define DMAR_ON 1 #define DMAR_DEFAULT_OFF -1 #define DMAR_USER_OFF -2 +#define DMAR_FW_OFF -3 extern int dmar_policy; =20 static inline bool dmar_policy_on(void) diff --git a/include/linux/dmar.h b/include/linux/dmar.h index 692b2b445761..63e35df2cef4 100644 --- a/include/linux/dmar.h +++ b/include/linux/dmar.h @@ -24,6 +24,7 @@ struct acpi_dmar_header; #define DMAR_INTR_REMAP 0x1 #define DMAR_X2APIC_OPT_OUT 0x2 #define DMAR_PLATFORM_OPT_IN 0x4 +#define DMAR_REMAP_OPT_OUT 0x8 =20 struct intel_iommu; =20 diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index bc2f6597eb27..33bfaeafa7c6 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -930,7 +930,9 @@ dmar_validate_one_drhd(struct acpi_dmar_header *entry, = void *arg) * * - DMAR_FORCEON_TBOOT: tboot strictly requires DMA remapping for secure * boot hence supersedes any user opts ("iommu=3Doff" or "intel_iommu=3D= off") - * and weaker off policies. + * and weaker off policies. But if firmware forces DMA remapping off (by + * setting DMAR_REMAP_OPT_OUT in the DMAR table), no force_on is allowed. + * Firmware settings must be changed to unblock tboot. * * - DMAR_FORCEON_PLATFORM: external-facing devices requires DMA * remapping to prevent malicious downstream external devices from @@ -939,6 +941,7 @@ dmar_validate_one_drhd(struct acpi_dmar_header *entry, = void *arg) * * In a nutshell, "trusted boot environment" is considered stronger than * "user choices", which in turn is stronger than "platform opt-in hint". + * But they are all meaningless when it's forced off by "firmware". */ bool dmar_can_force_on(enum dmar_force_on force_on) { @@ -976,31 +979,42 @@ static bool dmar_required(void) =20 void __init detect_intel_iommu(void) { - int ret; struct dmar_res_callback validate_drhd_cb =3D { .cb[ACPI_DMAR_TYPE_HARDWARE_UNIT] =3D &dmar_validate_one_drhd, .ignore_unhandled =3D true, }; + struct acpi_table_dmar *dmar; + int ret; =20 down_write(&dmar_global_lock); if (no_iommu) dmar_policy =3D DMAR_USER_OFF; =20 ret =3D dmar_table_detect(); - if (!ret) - ret =3D dmar_walk_dmar_table((struct acpi_table_dmar *)dmar_tbl, - &validate_drhd_cb); - if (!ret && !iommu_detected && dmar_required()) { + if (!ret) { + dmar =3D (struct acpi_table_dmar *)dmar_tbl; + ret =3D dmar_walk_dmar_table(dmar, &validate_drhd_cb); + } + + if (ret) + goto out; + + if (dmar->flags & DMAR_REMAP_OPT_OUT) { + dmar_policy =3D DMAR_FW_OFF; + pr_info("Firmware forces DMA remapping off\n"); + pr_info("Any user opt or tboot/platform force_on will be ignored\n"); + } + + if (!iommu_detected && dmar_required()) { iommu_detected =3D 1; /* Make sure ACS will be enabled */ pci_request_acs(); } =20 - if (!ret) { - x86_init.iommu.iommu_init =3D intel_iommu_init; - x86_platform.iommu_shutdown =3D intel_iommu_shutdown; - } + x86_init.iommu.iommu_init =3D intel_iommu_init; + x86_platform.iommu_shutdown =3D intel_iommu_shutdown; =20 +out: if (dmar_tbl) { acpi_put_table(dmar_tbl); dmar_tbl =3D NULL; --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 9F29844684B for ; Tue, 4 Aug 2026 23:54:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887698; cv=none; b=VyA9BmiTGMHvScDWWfjmLvRu6Px0+4okineSq3xwxK7QRr2aqvDclg5ZU/DEmqFRX1KRnVdmrrF+2lXjz45GKnmqu0gxggOiBj5FoSKazn6jyHS/PWWVrL7bRUtS2wp6KxToPXhheV9IylXcfURzY40YmeWbpQQitgRBumbSgY4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887698; c=relaxed/simple; bh=bYxhmqmIFX9Vs3YJLdvrfZ/i13mZ7a4GJErjKqVa80A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y78V5LakKu++prcRXfMWOoI+iqq3d2txql3wo5SKnhX/n5ewUwvEag/Fr848JWHxzMOvWzIc8PFZlxgw5c/bfsLoMDGAQIfmmyK8guLIix7AyCB0+z7Q+js5KaRYIfLwPhS7OP8Z6pt7g2MCrUW6k3Nq8+D3f9Ss58Tz2gWl2fs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=K2QtJuQZ; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="K2QtJuQZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887697; x=1817423697; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=bYxhmqmIFX9Vs3YJLdvrfZ/i13mZ7a4GJErjKqVa80A=; b=K2QtJuQZeLLubPL8d/ci2JSmGCLaf8OZM0O1/zF2JLxQANk7K9eKCRxJ v/Mref/E7E3lijg5OSidr4V6MddRQizWRP6Hxbp4+XuAG3uGleAKEjaPH +XquWQKV4WrlhoianaJ0Zr1/+0W0f1UqY40SD0wFiUtS9rCjElm3uOWUe bDsYxXE4+m/tOGe50qhRHFSoGe+Dcr9QYlZWvfCoxi2z/Ctu5wtPxQ1VT ZBI385kmNcuzZ3taxE5RRsZ/GaDXCKwgkYWpZUheOKkP3feRi12pbQ6V7 kCoLDC4w+qmA2oNEpihoHdCGXu5IueV2TqOCL66IqNYAWIuSFLq7+IjHK A==; X-CSE-ConnectionGUID: FlTiticuTc6UXmBG+fm1lg== X-CSE-MsgGUID: O3tycDqFQIqgLBnkPg9rzg== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263334" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263334" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:56 -0700 X-CSE-ConnectionGUID: 48gCkU9NTdG3orqSzVx+6Q== X-CSE-MsgGUID: ZkGQZCeSRyy43/R/X+3/gQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324397" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:54 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 14/19] iommu/vt-d: Cache max domain ID to avoid redundant calculation Date: Wed, 5 Aug 2026 07:43:08 +0800 Message-ID: <20260804234314.3087110-15-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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 cap_ndoms() helper calculates the maximum available domain ID from the value of capability register, which can be inefficient if called repeatedly. Cache the maximum supported domain ID in max_domain_id field during initialization to avoid redundant calls to cap_ndoms() throughout the IOMMU driver. No functionality change. Signed-off-by: Lu Baolu Signed-off-by: Xu Yilun Reviewed-by: Kevin Tian --- drivers/iommu/intel/iommu.h | 1 + drivers/iommu/intel/dmar.c | 1 + drivers/iommu/intel/iommu.c | 10 +++++----- 3 files changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 656cd311ed9a..c00f44db0020 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -700,6 +700,7 @@ struct intel_iommu { /* mutex to protect domain_ida */ struct mutex did_lock; struct ida domain_ida; /* domain id allocator */ + unsigned long max_domain_id; unsigned long *copied_tables; /* bitmap of copied tables */ spinlock_t lock; /* protect context, domain ids */ struct root_entry *root_entry; /* virtual address */ diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index 33bfaeafa7c6..c854173f6be9 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -1174,6 +1174,7 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd) spin_lock_init(&iommu->lock); ida_init(&iommu->domain_ida); mutex_init(&iommu->did_lock); + iommu->max_domain_id =3D cap_ndoms(iommu->cap); =20 ver =3D readl(iommu->reg + DMAR_VER_REG); pr_info("%s: reg_base_addr %llx ver %d:%d cap %llx ecap %llx\n", diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index a996b72aca57..5ea584b76f77 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1047,7 +1047,7 @@ int domain_attach_iommu(struct dmar_domain *domain, s= truct intel_iommu *iommu) } =20 num =3D ida_alloc_range(&iommu->domain_ida, IDA_START_DID, - cap_ndoms(iommu->cap) - 1, GFP_KERNEL); + iommu->max_domain_id - 1, GFP_KERNEL); if (num < 0) { pr_err("%s: No free domain ids\n", iommu->name); goto err_unlock; @@ -1111,7 +1111,7 @@ static void copied_context_tear_down(struct intel_iom= mu *iommu, did_old =3D context_domain_id(context); context_clear_entry(context); =20 - if (did_old < cap_ndoms(iommu->cap)) { + if (did_old < iommu->max_domain_id) { iommu->flush.flush_context(iommu, did_old, PCI_DEVID(bus, devfn), DMA_CCMD_MASK_NOBIT, @@ -1511,7 +1511,7 @@ static int copy_context_table(struct intel_iommu *iom= mu, continue; =20 did =3D context_domain_id(&ce); - if (did >=3D 0 && did < cap_ndoms(iommu->cap)) + if (did >=3D 0 && did < iommu->max_domain_id) ida_alloc_range(&iommu->domain_ida, did, did, GFP_KERNEL); =20 set_context_copied(iommu, bus, devfn); @@ -2431,7 +2431,7 @@ static ssize_t domains_supported_show(struct device *= dev, struct device_attribute *attr, char *buf) { struct intel_iommu *iommu =3D dev_to_intel_iommu(dev); - return sysfs_emit(buf, "%ld\n", cap_ndoms(iommu->cap)); + return sysfs_emit(buf, "%ld\n", iommu->max_domain_id); } static DEVICE_ATTR_RO(domains_supported); =20 @@ -2442,7 +2442,7 @@ static ssize_t domains_used_show(struct device *dev, unsigned int count =3D 0; int id; =20 - for (id =3D 0; id < cap_ndoms(iommu->cap); id++) + for (id =3D 0; id < iommu->max_domain_id; id++) if (ida_exists(&iommu->domain_ida, id)) count++; =20 --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 CEA424508E4 for ; Tue, 4 Aug 2026 23:55:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887703; cv=none; b=DJ8oiP2sKJ4prAxSjlj+8EsaPPHd7qUoykDF7bCFiFuSsvaPMUd+nEew/lpAn3GnPHVz0mQwJyRJzovFV8Wa2CbyNcISeERO/CA911nN+po+M3qI0778LBjcXYHm2U10ZWF3M75CQxGYIjcwQ+R1SrWQM2zLiNQ+HsByjr5a4hg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887703; c=relaxed/simple; bh=9NljmWmOa7zf85w1KhZzM5Q3pk7MPOLgw1HR0hX9Rhw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RZvyrHNtnNxyZQQNhN4UELVgc1FC0jiJgM6N6uqnXt4+0dhGcaFDp2vBAF0nuzcmR1zcIEewZirjgrnBtOQsEdYRAFVDUaxcjyxPEs1qGoC1G6Ys6d64pkuFTE/BErgfoHAbgJjrTU+IGI+FMJbV7hxSfS4sgSU11al2V0clONs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=hW7CZhQJ; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="hW7CZhQJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887702; x=1817423702; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=9NljmWmOa7zf85w1KhZzM5Q3pk7MPOLgw1HR0hX9Rhw=; b=hW7CZhQJRA/SnryoMciGD3JFa1AqZWk45SvIMB/YOMScvW8JC6XakpRn nwXLEbyRUvT0wPC9ien4j8xuSQQLpyjlUKP2MDJUQiYc33TI2+LSUsKpH w89mLphiIB+y04QP/87uAZVeRzf4gDIelUYnhKNcyCwkrKzN9wGzwj3t2 rhmjU3yBZUbJGtFzUG0sUYFyK6SAOfR0PbOmag9NWDFBo82PNfYdqPfL3 GVLl9lfUpodZbCh0hy9Tp9WIh7QOQAfvSM17+2bCfntvq9wXLM9KWJjkT /C3xqseUr/uSHEo6ACjG+ezHOGBdQDuD1h0cu0U8Tr5LXlDA0otItu1A9 w==; X-CSE-ConnectionGUID: XiSHMN5NSfmBNG0N4nwDjg== X-CSE-MsgGUID: CjpbH/WkTbSA5XMc6fLDEw== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263343" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263343" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:54:59 -0700 X-CSE-ConnectionGUID: U+mK/9tUQYmO0IC50+/XVA== X-CSE-MsgGUID: hRrGd4yAQpeBMWibucZyLQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324402" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:56 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 15/19] iommu/vt-d: Fix copied_tables bitmap leak on error in copy_translation_tables Date: Wed, 5 Aug 2026 07:43:09 +0800 Message-ID: <20260804234314.3087110-16-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" From: ZhaoJinming The iommu->copied_tables bitmap was introduced by the IOMMU live update series to track which context entries have been copied from the previous kernel. The allocation via bitmap_zalloc() was added inside copy_translation_tables(), but the error paths were not updated to free it: 1. When old_rt_phys is 0 (invalid root table address) 2. When memremap(old_rt_phys) fails 3. When kcalloc for ctxt_tbls fails (goto out_unmap, which only unmaps old_rt without releasing the bitmap) The bitmap is only cleaned up by free_dmar_iommu(), which is called from the free_iommu error label in init_dmars(). However, when copy_translation_tables() fails, init_dmars() does not jump to free_iommu -- it logs the error, falls through, and continues with the next IOMMU. As a result, copied_tables is leaked. Fix this by converting the two early returns to goto a new err_free_bitmap label, and by making out_unmap fall through to it so that the bitmap is always freed on any error path. The success path performs memunmap(old_rt) inline and returns 0 directly, since copied_tables must remain allocated for subsequent use. Signed-off-by: ZhaoJinming Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 5ea584b76f77..7098a6bf6a40 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1557,12 +1557,16 @@ static int copy_translation_tables(struct intel_iom= mu *iommu) return -ENOMEM; =20 old_rt_phys =3D rtaddr_reg & VTD_PAGE_MASK; - if (!old_rt_phys) - return -EINVAL; + if (!old_rt_phys) { + ret =3D -EINVAL; + goto err_free_bitmap; + } =20 old_rt =3D memremap(old_rt_phys, PAGE_SIZE, MEMREMAP_WB); - if (!old_rt) - return -ENOMEM; + if (!old_rt) { + ret =3D -ENOMEM; + goto err_free_bitmap; + } =20 /* This is too big for the stack - allocate it from slab */ ctxt_table_entries =3D ext ? 512 : 256; @@ -1606,11 +1610,14 @@ static int copy_translation_tables(struct intel_iom= mu *iommu) =20 __iommu_flush_cache(iommu, iommu->root_entry, PAGE_SIZE); =20 - ret =3D 0; + memunmap(old_rt); + return 0; =20 out_unmap: memunmap(old_rt); - +err_free_bitmap: + bitmap_free(iommu->copied_tables); + iommu->copied_tables =3D NULL; return ret; } =20 --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 B8CA9455188 for ; Tue, 4 Aug 2026 23:55:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887705; cv=none; b=M97y1Kcz8Xe5y74e57xJJmY6G4poPJqj1wYPzd0Q/M+raP+rBoWMmDDZdUB8dpG/P78PanZ5NRgHK4jptboGkuGnKd9rR37mHTv3vPvnTeJOX0NE+fzhPSG29tiDf314HC9Ybq0DA+ubtrpJTTLyjH/zdutSvHR/IIQ7m0iLU48= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887705; c=relaxed/simple; bh=kGVbd9pnieA+4WkKdGphqkjUnjw6m66qlFoy3/Q6/+8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WEqDq840ngB6kHAKFhY2uR+YcJZUNDnQzIzRBB3J1nKPs1L4X6mTuzugFcrM22HH9QLLdYURGOSFdWlWmAztyGtC1OPvhM2xfYmDe5/NSID7eWbt2un70X2lWnjom7m3PXCHiFK+Ch0agFX+eQozLazY047AMV3JnJcID3YK/e8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=YRJ7uCAx; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="YRJ7uCAx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887703; x=1817423703; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kGVbd9pnieA+4WkKdGphqkjUnjw6m66qlFoy3/Q6/+8=; b=YRJ7uCAxCRfXBI+xtbeguMFtdUepdkfGhBujEVlZmOssW11Ze+h9XB45 d1kDv2x2k8zwL1hLiBEzvMJGhSULoo3EY1nVGYuxIBjhB4mUWiYh/aH7C zZkPOqjUBAV5CJNf09Tx+GIWk6P18gYStt7NUoR2kbjq6O+gW/Pbwpiaz W//kIH1haioXWt94sZ6yiYVgDDSeuh7NGac7wPkTNvXKpOut2UYjPHVUI SHJJJCg7Mx3YLZF5phjkJmUXK3t1SmhNtLKPHOxdOkUeF/nIS122VnL+r j21IjpLpA5s3Z8q44T7+kzK7TfuErfs73UFl9WujQ2AWH46W+S7Nvmxpd A==; X-CSE-ConnectionGUID: AAzc0597SNSl4yG77RjVCw== X-CSE-MsgGUID: 38b9ovfCRrmhfxFLcNQOsQ== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263357" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263357" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:55:01 -0700 X-CSE-ConnectionGUID: JbYPTfqsR56v5E2WkYEcmQ== X-CSE-MsgGUID: vekvkBkISxe4qA1FECzjzA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324405" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:54:58 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 16/19] iommu/vt-d: Clear Present bit before tearing down copied context entry Date: Wed, 5 Aug 2026 07:43:10 +0800 Message-ID: <20260804234314.3087110-17-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" copied_context_tear_down() zeroes the 128-bit context entry with context_clear_entry() while the Present bit is still set, and only then issues the context-cache and IOTLB invalidations. This leaves a window in which hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behaviour or spurious faults. While x86 provides strong write ordering, the compiler may reorder the writes to the two 64-bit halves of the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. There is no cacheline flush before the invalidation either, so on an IOMMU without coherent access to the context table the zeroed entry may not be visible to hardware at the point the invalidation is submitted. Apply the same ownership handshake described in the VT-d spec, Section 6.5.3.3 ("Guidance to Software for Invalidations"): clear only the Present bit, flush it out to the IOMMU, perform the invalidations, and only then zero the remainder of the entry. Fixes: c7191984e5aad ("iommu/vt-d: Factor out helpers from domain_context_m= apping_one()") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40l= inux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 7098a6bf6a40..000b81cf4a7a 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1109,7 +1109,8 @@ static void copied_context_tear_down(struct intel_iom= mu *iommu, assert_spin_locked(&iommu->lock); =20 did_old =3D context_domain_id(context); - context_clear_entry(context); + context_clear_present(context); + __iommu_flush_cache(iommu, context, sizeof(*context)); =20 if (did_old < iommu->max_domain_id) { iommu->flush.flush_context(iommu, did_old, @@ -1120,6 +1121,9 @@ static void copied_context_tear_down(struct intel_iom= mu *iommu, DMA_TLB_DSI_FLUSH); } =20 + context_clear_entry(context); + __iommu_flush_cache(iommu, context, sizeof(*context)); + clear_context_copied(iommu, bus, devfn); } =20 --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 C3E48444712 for ; Tue, 4 Aug 2026 23:55:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887705; cv=none; b=oiaf5n0LSPbN+q4Cb31zJi0ZpItBUlYw444RYER4KGVRMaTOGof534yEVVSBZMj/KKGmEFUjZCs2/YNiD7/EJdolbHIBl0nUdxAGi4TbzvI/11wz9m7nrlL7U21Jj5cBd1lw2Fc77Uji+RzTa4ivkGmKkdx1n7IB+4Nc50LW/sg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887705; c=relaxed/simple; bh=0hEoNuRKl+qs3eW7LpOd8AxqJYyeaodBDnjTITybW1k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=C5cTJ+Zk+/cMyuAgNcxW4/HOa/NTXfwGJostT9k2AtVecwHnSQPhr9f/J9KBONtAErRHHmNSyI9+iRY5JARqTLsBrkIByVEwBwnNyFiByRUmYJakK5lkxnEOlSX9sKroSPnVP5nDXuCMVTGh9Nt/SrMS1jQa4UVy2Z58C8BPiio= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Ezcpb6Cw; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="Ezcpb6Cw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887704; x=1817423704; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=0hEoNuRKl+qs3eW7LpOd8AxqJYyeaodBDnjTITybW1k=; b=Ezcpb6CwR9EvTyqh7/lh0zpQKc63R3maKpWq987czXvzjTyRa0OBnvwA 4bKFjACcpvT3ka3uLE8Qi1OwlGi+LZV8ywXIJ8XLb9+BizzOBkS6TNAuf EyKx8HNqeA9y+VKC7oz3LEnV2k2Z8AyLF27RxrK4/yBEj8crsZppZB7CT Vy1wIgF6Pn3rk0GawkVQc2zPOoip3qOl6oAfm/SFpIGHdEKDx+0WQW80z aMFyvwn5DZtpwE/CJHMkDhfMmluGcDvz83EFHqUoqCgysMugDZ7hsf3cH aZyDTvRdrpya8IX+BNZYstJzOsxMRY08hcdTqmDw6LlE2ENaarTsuNsgX g==; X-CSE-ConnectionGUID: W7lMDeXGQoi4k0Q0A5kJlQ== X-CSE-MsgGUID: QALY8RrnRvOeqLSjDi0vzg== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263368" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263368" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:55:03 -0700 X-CSE-ConnectionGUID: mOtJUMH2TdCDR1uSecgebQ== X-CSE-MsgGUID: dMkpvY2LRRKoNqIKQP/Bqg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324409" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:55:01 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 17/19] iommu/vt-d: Fix iopf_refcount leak on RID domain replacement Date: Wed, 5 Aug 2026 07:43:11 +0800 Message-ID: <20260804234314.3087110-18-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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" intel_iommu_attach_device() enables IOPF for the new domain but never disables it for the old one. device_block_translation(), called at the start of the function, tears down translation but does not touch any IOPF state; blocking_domain_attach_dev() has to call iopf_for_domain_remove() explicitly before invoking it for exactly this reason. identity_domain_attach_dev() has the same problem. Its comment claims that no PRI handling is needed because the device has been put in the blocking state, but the blocking state and the IOPF reference count are independent of each other. As a result, replacing a domain that has an iopf_handler with another domain at RID level leaks a reference in info->iopf_refcount. The count never drops back to zero, so iopf_queue_remove_device() is never called and iommu_disable_pci_pri() triggers its WARN_ON(info->iopf_refcount) when the device is released. The PASID paths already handle this correctly by way of iopf_for_domain_replace(); convert the two RID paths to do the same. Using the replace helper rather than a bare remove keeps the enable before the disable, so the reference count does not transiently reach zero and evict the device from the IOPF queue. Fixes: 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach path= ") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40l= inux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 000b81cf4a7a..9003783d02bc 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3152,13 +3152,13 @@ static int intel_iommu_attach_device(struct iommu_d= omain *domain, if (ret) return ret; =20 - ret =3D iopf_for_domain_set(domain, dev); + ret =3D iopf_for_domain_replace(domain, old, dev); if (ret) return ret; =20 ret =3D dmar_domain_attach_device(to_dmar_domain(domain), dev); if (ret) - iopf_for_domain_remove(domain, dev); + iopf_for_domain_replace(old, domain, dev); =20 return ret; } @@ -3861,10 +3861,13 @@ static int identity_domain_attach_dev(struct iommu_= domain *domain, return 0; =20 /* - * No PRI support with the global identity domain. No need to enable or - * disable PRI in this path as the iommu has been put in the blocking - * state. + * The identity domain has no iopf_handler, so no IOPF reference is + * taken for it. The reference held by the old domain must still be + * released here; putting the device in the blocking state above does + * not affect the IOPF reference count. */ + iopf_for_domain_remove(old, dev); + if (sm_supported(iommu)) ret =3D intel_pasid_setup_pass_through(iommu, dev, IOMMU_NO_PASID); else --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 9AB184503E7 for ; Tue, 4 Aug 2026 23:55:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887707; cv=none; b=uTGWqsKdE15OZDYghoXi+VJzVemg1HVajyqtlSYpLSdHSVEy8oosuWuCXxgb7EkuZdZFvzdabfQ4SzJcXKcUCiQI8TFrxrWNqjHuritL5sBDac5SzJNvklumnRhuxR07LtPUTpJzRjS5Adrn6EqNByGiZDaneyiqVhc5rYxCIRI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887707; c=relaxed/simple; bh=pnwJe36D1sL/gNEszmY3UecgU2zT9dRDC3/tQgH4P6c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=BFMe+7J0DspqUmvXiqo0DrwNOb1GZcGoQqC/lhNGmEyA0Fk6AdXMP8aI9hJzSK3OEBJ/ipJdSpUr5qUsKbDwQ5BsDLVWv0VpiypNVLOkYCJzP7ixUp2fKqjbUWyeBheO2nYrLSzQZFUlxcYx6cE2Se0Oly34AVTFqAKtF9wymS8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=GkEht/3i; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="GkEht/3i" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887706; x=1817423706; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=pnwJe36D1sL/gNEszmY3UecgU2zT9dRDC3/tQgH4P6c=; b=GkEht/3iiFI+UuaJN7VZqr95VHvYo+zrRy7rswkNjAqhX6wq4NCJo/dJ e2TZm5oMPASEVrnTdJmZMpgyvlABmjAJ3/K987KamqYTb0eYqYqsk/w6s gniPEt5x55V1Giu8+gvFN0RlXfU2Nxam72Nv/geOC73cBDLdaSfIL4KYV sXrXdBpk+jCxb0GbM8AFGlLOCOtM4cYxmGvfF+rtIMuMaBskd33+sG3RQ kQ3puSHnaL6Rj6qSpKMjDVrYISBZ//g78RQ72I2+HndPfRN43A9VuLsX7 3Mgrndws542oWYS0rRl1UB4OgPcTHwK5TysFSZPcxm+pLM4W7764+EJ9n g==; X-CSE-ConnectionGUID: Grxy8zMHSKCxBHinhNsSBQ== X-CSE-MsgGUID: Mc8xTnILR7GUyCWEyDJnZA== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263377" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263377" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:55:06 -0700 X-CSE-ConnectionGUID: v8eD0TBqTIOK4IcULSR5xg== X-CSE-MsgGUID: GL942qVfRXmEpTJ29YBrkA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324416" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:55:03 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 18/19] iommu/vt-d: Tear down scalable-mode context on probe failure Date: Wed, 5 Aug 2026 07:43:12 +0800 Message-ID: <20260804234314.3087110-19-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable intel_pasid_setup_sm_context() walks a PCI device=E2=80=99s DMA aliases via pci_for_each_dma_alias() and programs a scalable-mode context entry for each RID. For a device with a dma_alias_mask, the callback is invoked once for the device=E2=80=99s own RID and once for each alias bit, all with= the same pci_dev, so device_pasid_table_setup() runs for multiple RIDs. pci_for_each_dma_alias() stops at the first callback error. Therefore, a failure partway through the walk can leave context entries for already processed RIDs present and still pointing to the device=E2=80=99s PASID tab= le. On this error path, intel_iommu_probe_device() currently jumps directly to intel_pasid_free_table(), which frees the PASID table without first tearing down those context entries. The IOMMU may then walk a present context entry whose PASID table pointer references freed memory. intel_iommu_release_device() already performs teardown before freeing the table. Apply the same ordering on the probe failure path. device_pasid_table_teardown() safely handles RIDs that were never programmed: iommu_context_addr() returns NULL when no context table has been allocated, and clearing the Present bit of an already non-present entry is a no-op. So unwind is safe for both the alias that failed and any aliases not yet reached. Fixes: 301f1a80487fd ("iommu/vt-d: Setup scalable mode context entry in pro= be path") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40l= inux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 9003783d02bc..489bab4999fb 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3333,6 +3333,7 @@ static struct iommu_device *intel_iommu_probe_device(= struct device *dev) =20 return &iommu->iommu; free_table: + intel_pasid_teardown_sm_context(dev); intel_pasid_free_table(dev); clear_rbtree: device_rbtree_remove(info); --=20 2.43.0 From nobody Fri Oct 2 05:28:41 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 7811745D5F2 for ; Tue, 4 Aug 2026 23:55:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887710; cv=none; b=OZ2s9R4016xViM5Ve+tNWxd2+5INX5IuhWWpi2SPj1k+EWkMWzMEmHI7fx+FGZrmUQE8QN4tsX32CnEUwq9tMz2giisIX7YuySlDx71siwGu5m4jr7zLlutrbm3QE6oE71O5iehxb4KXouaGD1J8uV9LnbTVdLcK7WHKkY82r1Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785887710; c=relaxed/simple; bh=Eb4X54a9JEu/mnegCruXzqQKDfrycys2omgDV3RSDWA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=JaKwYXrMy7MyUr4xHIg9gXzftZ6npND1UucMtFAz8vCo/AgpUta+srv62S2A5LdlrxHGaDDO4PMqb98cNEbBHowALQQa4shqcTVBlk8oeGTG46aYL/MzXjJiTFqcVobe/3mF0qq54iflWs1Ju3dHff4F7/uQFo+kMA3zzT126c0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=jCsjrA0P; arc=none smtp.client-ip=192.198.163.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass 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="jCsjrA0P" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785887709; x=1817423709; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Eb4X54a9JEu/mnegCruXzqQKDfrycys2omgDV3RSDWA=; b=jCsjrA0PP42XJeQV2VRNg4p/cBGUcLONijvB8Bid5JNTxd/3heP6Ixug 9vJQdYc+UC/9VxwupcEC532ts75utPK9PTlK5Jqcs2ZmK4ZAYzdWVBx0U r9nmqxvmuf5dP//Bvixj7jkB/8BJikxfg0TdUMYcmW6e7J7m8dTwjqkpL 5AcQB5HhYCT+AIlSQzxW9OSHupM20JPFWtkLvPoC05GzEvA6xnwwhzGVo k1T244+vQxwBLIN4qc4QfVkNAnhB+KEv7j3yfP6RCBuwMZtB7fOwfixNq MqIbq0D3/tclOGbyoePIeCc4QdzbR/kbwBrXA4bpj9g/QwRySNon56g2R A==; X-CSE-ConnectionGUID: 7nEuKzEVR0ajhncBoPnpZQ== X-CSE-MsgGUID: 2ck/JnXbQC+TQawR5XCW/Q== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="90263389" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="90263389" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 16:55:08 -0700 X-CSE-ConnectionGUID: vRkYKsBcQQiCNnYV+2Ji5Q== X-CSE-MsgGUID: iDkfASHXTOuB5bCa45yTBw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="257324434" Received: from allen-box.sh.intel.com ([10.239.159.52]) by fmviesa006.fm.intel.com with ESMTP; 04 Aug 2026 16:55:06 -0700 From: Lu Baolu To: Joerg Roedel Cc: ZhaoJinming , Kevin Tian , Dmitry Antipov , Guanghui Feng , Li RongQing , Desnes Nunes , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH v2 19/19] iommu/vt-d: Flush context cache with correct SID when tearing down aliases Date: Wed, 5 Aug 2026 07:43:13 +0800 Message-ID: <20260804234314.3087110-20-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804234314.3087110-1-baolu.lu@linux.intel.com> References: <20260804234314.3087110-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-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable domain_context_clear_one() and device_pasid_table_teardown() are both invoked once per DMA alias of a device. Each function locates the context entry using the bus/devfn pair provided by the pci_for_each_dma_alias() callback, then calls intel_context_flush_no_pasid(), which constructs a device-selective context-cache invalidation from info->bus and info->devfn (that is, always the requester ID of the device itself). As a result, for every alias other than the device=E2=80=99s own RID, the c= ontext entry that was just cleared in memory is never invalidated in the context cache. Hardware may continue using that stale cached entry. In the scalable-mode teardown path, intel_pasid_free_table() can then free the PASID directory still referenced by that stale entry, allowing the IOMMU to walk freed memory. Fix this by passing the source ID of the entry being torn down to intel_context_flush_no_pasid(), instead of deriving it from @info. Fixes: f90584f4beb84 ("iommu/vt-d: Add helper to flush caches for context c= hange") Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260602233426.357499-1-baolu.lu%40l= inux.intel.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Reviewed-by: Samiullah Khawaja --- drivers/iommu/intel/iommu.h | 2 +- drivers/iommu/intel/iommu.c | 2 +- drivers/iommu/intel/pasid.c | 9 ++++++--- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index c00f44db0020..23dbe6c24439 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1241,7 +1241,7 @@ void cache_tag_flush_range_np(struct dmar_domain *dom= ain, unsigned long start, unsigned long end); =20 void intel_context_flush_no_pasid(struct device_domain_info *info, - struct context_entry *context, u16 did); + struct context_entry *context, u16 did, u16 sid); =20 int intel_iommu_enable_prq(struct intel_iommu *iommu); int intel_iommu_finish_prq(struct intel_iommu *iommu); diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 489bab4999fb..6d81644c66bc 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1251,7 +1251,7 @@ static void domain_context_clear_one(struct device_do= main_info *info, u8 bus, u8 context_clear_present(context); __iommu_flush_cache(iommu, context, sizeof(*context)); spin_unlock(&iommu->lock); - intel_context_flush_no_pasid(info, context, did); + intel_context_flush_no_pasid(info, context, did, PCI_DEVID(bus, devfn)); context_clear_entry(context); __iommu_flush_cache(iommu, context, sizeof(*context)); } diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c index 81353fd46b37..e4f24d3f19a6 100644 --- a/drivers/iommu/intel/pasid.c +++ b/drivers/iommu/intel/pasid.c @@ -751,7 +751,7 @@ static void device_pasid_table_teardown(struct device *= dev, u8 bus, u8 devfn) context_clear_present(context); __iommu_flush_cache(iommu, context, sizeof(*context)); spin_unlock(&iommu->lock); - intel_context_flush_no_pasid(info, context, did); + intel_context_flush_no_pasid(info, context, did, PCI_DEVID(bus, devfn)); context_clear_entry(context); __iommu_flush_cache(iommu, context, sizeof(*context)); } @@ -955,9 +955,12 @@ static void __context_flush_dev_iotlb(struct device_do= main_info *info) * This helper can only be used when IOMMU is working in the legacy mode or * IOMMU is in scalable mode but all PASID table entries of the device are * non-present. + * + * @sid identifies the context entry that was modified, which may be a DMA + * alias of @info->dev rather than its own requester ID. */ void intel_context_flush_no_pasid(struct device_domain_info *info, - struct context_entry *context, u16 did) + struct context_entry *context, u16 did, u16 sid) { struct intel_iommu *iommu =3D info->iommu; =20 @@ -967,7 +970,7 @@ void intel_context_flush_no_pasid(struct device_domain_= info *info, * when operating in scalable mode. Therefore the @did value doesn't * matter in scalable mode. */ - iommu->flush.flush_context(iommu, did, PCI_DEVID(info->bus, info->devfn), + iommu->flush.flush_context(iommu, did, sid, DMA_CCMD_MASK_NOBIT, DMA_CCMD_DEVICE_INVL); =20 /* --=20 2.43.0