From nobody Fri Oct 2 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 5BA173590C3 for ; Tue, 4 Aug 2026 02:48:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811708; cv=none; b=T9Ak0iFac70Juq/Aca6iLZ7p1Sj15kuHq1hMEUWcpmeHNrO2ia58RB8F6wylmnFl4F1APkBhbqGnbK4QoNsa4vE/vKmU6ddYywIJykr6xsBNywYXUBpSfeuskgsU+pPWJtrlBZ+2jSBTh4myyI34SKYRwHXD1HZFdcopY2MFEq0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811708; c=relaxed/simple; bh=fSdEyytzPOzQz2lGc2NNfCDE0HdpxFXJSWsj0N4NZno=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G8NaY7LFvnAdCKSujix8kMsFAvGqW2Zx1DPqZM5YTvhZAZb/LGKIkxBIkAlFHjFOCMAldtyj4/DnvHp+B61pr5bJpM4O8flwR4OyGd9bZ0/+omKNtfDs1sM6+2kCliN4TaktqjvuT+wHKkNWn1nqYOCgSJE2ZAmqtODubsBFmeQ= 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=GYFpQv/H; arc=none smtp.client-ip=192.198.163.17 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="GYFpQv/H" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811707; x=1817347707; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=fSdEyytzPOzQz2lGc2NNfCDE0HdpxFXJSWsj0N4NZno=; b=GYFpQv/HHunsF982W1K42/meydh0NV+x5jbg0L6ImA9CAYCTwfg7WpM8 AlR6hMrbhVaBJf9IRHCSev+eTkYi0NORnsm6BeZima/777TUJeN3Ar3TS 9wybkgbdv468ymTBsj4l2WgwKkHQa/2ZgqNYGVJFFELJ8UlJz1f93kDRS L0YAjY0hokoUd6fSdIaUn9CUbJ2iCeMaqecy1zhkIBNEwpYVHJyrt6/7d 7AHeJIQaaFejegzpKi+iHQEbJbv+fyan2dMgpz22rRNWZONAY96uw5a7r 68F3+80sTFySm4LgWJ/PWyTUM6VAyNJJw3VbYO7k/WEoQrK0Hh4XbLx0w Q==; X-CSE-ConnectionGUID: JG+zCbUdQUO8uxNu6eRlhg== X-CSE-MsgGUID: 3ASZ6tlLRky/QEGGRCMJuw== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231219" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231219" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:26 -0700 X-CSE-ConnectionGUID: 8MEKhmSASJ6FRK5VIRwXzg== X-CSE-MsgGUID: AsScwTSGQ7yVnFSvUjfpBg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587393" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48:24 -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 01/20] iommu/vt-d: Fix UCTP context table slot when copying root entries Date: Tue, 4 Aug 2026 10:36:55 +0800 Message-ID: <20260804023714.3080506-2-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 2A6163F8883 for ; Tue, 4 Aug 2026 02:48:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811710; cv=none; b=Yw2hNwF+NMRBfM2YUDfpQc0OXjRXHlR9gw+BBfm3mmLLel01G7HCig4k+MH/8sRq1Ad8nfjEb4XfomDKYYh/SW3C7BfHhtzd+qc5V1sbZeEE8ic0hFzJEX/8Ysse0sgJEvkSP4kijZEiyRdEDYoZbU5iJ8PfGI9mpDMpQEfTyx8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811710; c=relaxed/simple; bh=NzOh9HpnXu8dPA60cF2rU7FEPlZpigtx/FS96NI3DkY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FRgsC7kkutiMJP+tyAFNY0EYquxkgwt/Ma7o2vTdHwwJRiQS0UNhEZDJmvab+1Ux/rcgS7h/a+mxn5Z6lmf4GEre9kztZDpsTFIosDu3bQFC7pTkpbFntQBR503d733Isra/seHSlGeK+jhs119Q8jomnsT0VkN58GbDQZNBliY= 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=V2ze/zWw; arc=none smtp.client-ip=192.198.163.17 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="V2ze/zWw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811708; x=1817347708; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=NzOh9HpnXu8dPA60cF2rU7FEPlZpigtx/FS96NI3DkY=; b=V2ze/zWwp2AQBHmqD1D0rwSHJQd7VqS9L2EmIG13fkA+BKX3CHQVoe8p XDVhGu2WhbUd6IT9knNlHOCmqy3311noyBifRVTLWGrRmxG+6f6ubkGFe bVVT4+q3YT2sx++bL4YxPouPYaiF7eTAw1PzstgQmSbib8jLEFZ131b9t WwjXVwZjbdvSQmwqQVv9dCuXb/qGox/kR8+Z7O6Z0UC1IuM535xFUOrl5 yj4V7QHt5erO719+8xbrzgBHMQoNRCxMqZ4ccQYeNAzQBde7Qv2SsUdBj zsk5cpWqPnUdcWCiCviMp6cqcrgDRXiEc//HEETgh3rQLKtoUYmgb69N7 w==; X-CSE-ConnectionGUID: YGDz4jnaRECXzKTwuDG9xA== X-CSE-MsgGUID: qPAk+1YzSEOhdh+reGTdlg== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231227" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231227" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:28 -0700 X-CSE-ConnectionGUID: fM1NofRNSw+IEGDkrWTtZg== X-CSE-MsgGUID: +NekXnV+RPWePW2IjoPMoA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587410" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48:26 -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 02/20] iommu/vt-d: Use logical OR operator for privilege mode check Date: Tue, 4 Aug 2026 10:36:56 +0800 Message-ID: <20260804023714.3080506-3-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 89FDD40DB27 for ; Tue, 4 Aug 2026 02:48:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811714; cv=none; b=IHa8nXA3yYGiI+E4ysRt7oD8J7FIM0zs435as57audCKbErpeScoSww7shsQKHw61WVia3x9BsCd/CYmUdwAXGWnP9sCOTD3zXFNM6yUr7rOJlh32U9qiJdpRrqwod6cW6xfLwyBaEm4Xauilxm+B64mxMpSQAmC4byLFtl9oB4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811714; c=relaxed/simple; bh=zamAuPAssF3V8Notwmfjg78q2xg+FerxZ7Cp1BRqTfQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Nr+ZW3fESo2wWcQbW3LoJh1AfWNs9BK1KiqTLo1bOSnPI332go/FN1fA+zI4oH1qatvgcDOrCoo2V34zHvzv7a0Wxq/nV+jQs41YvIjky067o6u3KiN2zcXst9jA8xVHxJ9yCnZByHTxbLjejC6tR87O/iTlZoC8wdaqBsGyGw4= 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=XZOoQswc; arc=none smtp.client-ip=192.198.163.17 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="XZOoQswc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811711; x=1817347711; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=zamAuPAssF3V8Notwmfjg78q2xg+FerxZ7Cp1BRqTfQ=; b=XZOoQswcsFjNub4KSqsY0cgqH2t6gFlPJaYrfA6nDExCPqjgd1BnfVQi aAzm1COY17bycVBOKuutsXh5JeDiZqK0S3HofwWgfqlGRiBfkNqklayvF Ywe0/8livODt1mFnpgly8I96UxvMr6BOl8qnokXlVEgLCVFlV1Hkksq8W spQPDxHHGFD1tfqHNY4L2PfhTR5nR47n1cdZl7OH6uVG/vKKNwFXfw0tA kp0C24xn3nI0gT0Z3XZoNfW3SIPU3YKcvq4QeAOiPTfbHXuWxzwp/y1MX 1vX3DmBuOrGb3X4YnvpptVDUAq+rbsAeFe6WUkUM+vxknu80ZybdxUjyV Q==; X-CSE-ConnectionGUID: 59GDyEDRQOmYUc7dstTMPQ== X-CSE-MsgGUID: KyuZCEU6RIGWUnezfS4/IA== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231235" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231235" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:30 -0700 X-CSE-ConnectionGUID: KkZTRTv4T0CA6CT725rIzw== X-CSE-MsgGUID: +D5owHTnQ0yS8ZdX+TZaGA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587431" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48: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 03/20] iommu/vt-d: Fix CACHE_TAG_NESTING_DEVTLB polluting shared variables in flush loop Date: Tue, 4 Aug 2026 10:36:57 +0800 Message-ID: <20260804023714.3080506-4-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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. 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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 B5DF6411FA6 for ; Tue, 4 Aug 2026 02:48:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811714; cv=none; b=ptYzbhiadYR6X6sQSSDEkw4AJClSrTAnvZIDtFXdsNQorwnLw7BbJVcQB2fBTWc1SehT1pgb5h86tI2tvXqCzGwVfygJkVeMHI4BfH41gzRCrVtK7mUDmaoJvkf2q3rdfNbmuacDWnTX0KG6fPGc1ptMLyfuOjokoJYRyAR3tSs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811714; c=relaxed/simple; bh=wvs5/3Vc8ATiENqbwg9FKEU2eKqwenz/FQk2i2ewikk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f67dQ3b8FdV+2JKkR3F5O/fxqeUz5Y2SBmoLiNnqF+CV8vFp22044EM2zUsvl81ZS7sOmr+dHtNPreR6/887PdLNISqn3Uf2Hzr2TFGD+kgrkkpJ4buH/27/VVdxfxI7BPlJ3NE/xiaygEq6bcJwh0Etp5Ni+xPF7nRzdvIUak0= 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=WMpt692h; arc=none smtp.client-ip=192.198.163.17 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="WMpt692h" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811713; x=1817347713; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=wvs5/3Vc8ATiENqbwg9FKEU2eKqwenz/FQk2i2ewikk=; b=WMpt692hgBBR2shLTg+Mnmgfhw8SANkkclLxMbWPVBJNQ8o6zIntnVql HkBPUemjUfsMGzJL4Ju9ipc908KTwsyvWoGiVaKrmNiQZkXz5/ZtHOZvk MJi8m3clvnt2MpB3UMWe0zgEVWn12t4+n0AnVT7A1AHeaEQhaexdR7Y73 J/S++QNR1hEstq02TjofroA6F0zHajCGO2qF1bJJu8jKktSAkHAE1QoRX 3hRynJeCGHYj1BItqyFczRXTIJO6hlWnu1DEViPk9hvIQ6QJ5SOLIHXS9 Wb2Gja5tIGLBZ12GU8wzf6DgadznGJYYksVXEeqdhrWDT4BBmRfyGeQUR A==; X-CSE-ConnectionGUID: z5SKZPIVSAKztR9qlElvAA== X-CSE-MsgGUID: mAkr/XdCTsmNa2RzxJG0MQ== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231243" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231243" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:32 -0700 X-CSE-ConnectionGUID: XW406pNNQ9eSVXqWEJ4TIg== X-CSE-MsgGUID: YyNt6JpmSuGHDNu/Dnq0CA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587457" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48: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 04/20] iommu/vt-d: Use kstrtoint_from_user() in dmar_perf_latency_write() Date: Tue, 4 Aug 2026 10:36:58 +0800 Message-ID: <20260804023714.3080506-5-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 835974137A2 for ; Tue, 4 Aug 2026 02:48:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811715; cv=none; b=Nknm7pITUD3OGb3ibA/YgAVHZYI/4Wa+8vNnl58axmlbf3Bb83c0umFoVefWuc6Jf9/bQB3pLzGuuJ/0lp7+2TzC+Im3NezxQGqeMVxCS+qeAdnW/rRpq0yD0JFOtGfc/lgZPFwWRt329L8cEVynJhjCLHYxXRgOIOp89iU8rdM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811715; c=relaxed/simple; bh=YDlwD9/B7SoUh5Cw/Q8HBWUAKwRQP4CubhpluDGbVfg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=u8PFAFHE6CmTOpmXZ+pRxki8wShPuHbHwU8N3xNPLWj1QxKF5fJKr/oDH+uVSFL/3n5WfpAbuSgQhxun+O5QAgpPiSSb5GWNB9DtUBPhBWCY8uz5ClVDc/t+6zxBp8risGtlA5WVvsW14hqZEsDpLuHggVdwqfyBAwzDnsoX6qE= 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=V3tjeRy+; arc=none smtp.client-ip=192.198.163.17 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="V3tjeRy+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811715; x=1817347715; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=YDlwD9/B7SoUh5Cw/Q8HBWUAKwRQP4CubhpluDGbVfg=; b=V3tjeRy+21daXBBtZAVLtuj2mkBJjBXbyWoMEUNtXnZgQxRJsfn/lV37 Ezg+VopjFQ7b/XPOXLC+KmVgeeKqlDrjWAS0UECgXywyAoz9FVQwHnGFj xQZP3m+oFpQvis6tffThLbeGhKLRu3hqXPDQFLH5OeFy37pDbwoVvnw1I 4gQ3tLbINouWj/EjsIy+aKqcAcUWfxkZJ0NeBCBkOIn4mLlnOdFWCgecu zixMYWpNXPxz0FR5IqFc7bSG51dnzXJcMU0nBETi0oslgfYRGPgsZIPEu b9FCkZ9nzTxkNcICE2e5/OWKmrGnFjV4PVROsLiuspWAKj7CGljhjJnjh w==; X-CSE-ConnectionGUID: MS3umrJYTdmlLu/upCFPVA== X-CSE-MsgGUID: SWB0/fxOTZKVdcYECugd2A== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231251" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231251" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:34 -0700 X-CSE-ConnectionGUID: reCLnf5YTBGBfaYwrWoyGg== X-CSE-MsgGUID: usZu3U3GTWKJsENiGkZKPQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587470" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48:33 -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 05/20] iommu/vt-d: Fix no_iommu to disable platform opt-in Date: Tue, 4 Aug 2026 10:36:59 +0800 Message-ID: <20260804023714.3080506-6-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 0F5A6411680 for ; Tue, 4 Aug 2026 02:48:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811720; cv=none; b=dX8GPnnRfs9Ez7ohE+Ji2Ef2WgYGvWxN3Ta4qYUDZHta+F6uvIjjZdRhhMwIjfaH6VkU+S3DErEq8samM5x6jmHKYD2+Hibk3EehiOo8bqrODYHl5HQJhQOK9T5Tzw3F0sofml4uW9PhLmEha8STFepTqJnS8ceMNfDqwZsOZXI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811720; c=relaxed/simple; bh=RHtZyNIndU8qQJD0heWZbkAT4r7eUBHP8fHD/4aUctk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nptdubnBavlPp0xBOuKAby8vnkKCMURS9AowLyQNKq6b/h1hpCaf19pQFVwqFvtZTxEZ8VfhngB/CcZobbfbjP7OlQqRYxUW3Jrv/7luvXo51+RHt1ZcelRnsYTaN/7Rp7aa8iGT1faD1ubJ/5W+gAy5ZrqLT/HnijS1XoAjIVw= 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=YfrpFZIa; arc=none smtp.client-ip=192.198.163.17 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="YfrpFZIa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811717; x=1817347717; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=RHtZyNIndU8qQJD0heWZbkAT4r7eUBHP8fHD/4aUctk=; b=YfrpFZIa0xq2lHubKdCoJjpDUl7eNyeUA3CnPxGbEMW2YRFzcV5/ss/T DCbUD7kYnxfxLAWqOssujHPXlLZsmy+F4CKiIpXDD7yCRTFN9rw8EIiet nUB6r3WPYVGkAuY4onI4IhIOxwq8IEUh1N+QI9gRK7yPRJyl9Bb2irquF o6fXw7gn4X+b4s+0f0uGN0l0Mz6Gvij1Al22GRIRj6iNTltBLkNfeQhl3 n9K3Mz17FaswmWvM1U9TB4JZpVWkMBLEk2aNhPk9J7so7yDDS1TRR/kdn im+MBhf/i8s+725YEHZcysFCGpgaogm6Mv7bHDvJpW/mo30T8yGlGCC+X A==; X-CSE-ConnectionGUID: GaXQ0gc/TqC+2ZqbSjRrow== X-CSE-MsgGUID: FhNfdHlSRYSUWV71zU7Lsg== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231259" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231259" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:37 -0700 X-CSE-ConnectionGUID: GbvbnbJHQsa7s/Nbn+d5Wg== X-CSE-MsgGUID: YMBsVD3wTjiXZ+fk1z5kxA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587481" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48: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 06/20] iommu/vt-d: Force requesting ACS when tboot is enabled Date: Tue, 4 Aug 2026 10:37:00 +0800 Message-ID: <20260804023714.3080506-7-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 2DA33386422 for ; Tue, 4 Aug 2026 02:48:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811720; cv=none; b=TahakwNta9ZXJigZM/YOf/5QDJrEb/Y3Nk6eviqPX/dr7jGqpt/iVU2pGUYlo0Q48bopybqeO9z3ynvTJpiF5PGmce35MaTbCgpqe15Sz/cABLvCATktFog85pUo+2PzWUrudlA4jFfPtGsf8qDGumTDzt6RLYj7nMLtD3qGIlw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811720; c=relaxed/simple; bh=Fms6Rbz+/KJEXKC76z5BRIO8rQtmau8kHn5raAO6hWY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SYbsaECU7aFlVp+cR9yQgw7gtnetSrVACMD+ezIQ6ld3/nEu/3vfPdtS01etHAYwmpmS6rOtksRZC8TNkDyOOFGTqOrOpFKt1WSa1OJG23nUVDu3JfQLeW5hRvJSy09fBZ4LqCZnPnGz1+dhw2D6SS9LrcdjemvczwoOPwnGKkI= 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=Eg/uTaBB; arc=none smtp.client-ip=192.198.163.17 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="Eg/uTaBB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811719; x=1817347719; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Fms6Rbz+/KJEXKC76z5BRIO8rQtmau8kHn5raAO6hWY=; b=Eg/uTaBB62zETG9k1V1kB3IyulyODcWAc6PCTejj8a0aGQ+I3RWkdWb/ Kg/5DwPTqVD63e429uo+lNmnh7WzlRXeIYNaSHx3/eTQLM1Cm2kAx6dA8 +EHhOzGR64zmbD+GfNer9BWcs92q5kCMBrfAineco9rBmT12GV5eVtA0g 4xcdiBVtSAiUrYbE3/dagW4odvxcnwQHezxmtw/75yc8dUYotMDDcMIck oz/UzPt33f85FSSxh9iv+L80zmUaWlR32FDvML3j4VN5FsnJKF8vx6H+z bQmxX3JoEEEPrqlnxzTXTuWeceMtQFwOmYDAhk43DX8HXG+Cel1Io2AW/ w==; X-CSE-ConnectionGUID: mvG2pfq5THGw89QWEg9AEA== X-CSE-MsgGUID: jt7mgPVIScWjDMqN5aSi2g== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231268" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231268" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:39 -0700 X-CSE-ConnectionGUID: OFqmluWSSPGS5c47jzdDQA== X-CSE-MsgGUID: xK6staLGRIS1x4vuCzDmgQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587494" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48: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 07/20] iommu/vt-d: Remove dead code when CONFIG_INTEL_IOMMU is not set Date: Tue, 4 Aug 2026 10:37:01 +0800 Message-ID: <20260804023714.3080506-8-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 A2FD136F434 for ; Tue, 4 Aug 2026 02:48:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811724; cv=none; b=TeFAJJLk9TrXEsX2jHlU/rIPCIVjVqW+gwSQcRNCcvH2J8ur77SEdyl3LODczLpQqDEZPm3Z3F5kCvt497G0c7KlAE21T6BcYOmZo0ijxQaR9olNNXizOBexVO43j8jOV5klc4rQb/Pnbo0ldSKoWFXfL7ts10xc1DMTAs9Si2U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811724; c=relaxed/simple; bh=SdZ/l+fYJwUzZGSzWTxaBMIaqf3zUpO7xK8W3xhNzzc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nB0veCl8L/TtqIbkaq20b1cWd7RfqVclpvhqTjgHLlhb8f6iFWdzr4POzIcz/tio2stvrPSjHnuS/Qi5YEymr3NSiprijIVHbthYz/bPHC3a4Fn9YMJSKXF2+ODSXxy67wrXrn91ugmDkK38CpaddA2Fg2IZI9S35/p1hDJaKoM= 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=nrkP+e+B; arc=none smtp.client-ip=192.198.163.17 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="nrkP+e+B" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811722; x=1817347722; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SdZ/l+fYJwUzZGSzWTxaBMIaqf3zUpO7xK8W3xhNzzc=; b=nrkP+e+Bee+4497eOG5zLliCcZPCtUSEr+X61hDATe/Z6TFkNgIRysIU 2X0cyc7XSqqJfD57bx2sRNf+RG9Ljm8nnp6OYPhraD0tD9tIstaDU4ju7 +VZ17WMC3MgTZRb6r/kRqCJ1QdDzNB6qHeBf4MDwiiW2YYt9HeEDFvM/i QWJ3QSbwiTvRZVuDajCiA9voPAPByqEPjMtS2meOm0cnd22DRuayipEcu RlMhPeBrmKrFMJqR/idTCP7zTMV29D8huKp2d9nUkW0pH269PZUVRT3Ug 1mFLKyer0YUE3OVVPmN6kFLifEFLs2DiFNN7JIcNPvtH3vETuY8OA/HKz A==; X-CSE-ConnectionGUID: rLEvMZm1To639qRKbyq+4Q== X-CSE-MsgGUID: PIM2ZkPPS5qmlDtU2ghxdQ== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231277" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231277" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:41 -0700 X-CSE-ConnectionGUID: RUiLhlSCTLu+ZnZ8t3obdw== X-CSE-MsgGUID: LIdaMIDtQP+9bC0fRZnvwA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587504" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48: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 08/20] iommu/vt-d: Consolidate dmar policy management and force_on logic Date: Tue, 4 Aug 2026 10:37:02 +0800 Message-ID: <20260804023714.3080506-9-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 9BE564137A2 for ; Tue, 4 Aug 2026 02:48:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811724; cv=none; b=OY8F0QnzepJExZIA79iMykX39zM2GQ/7cfhLrZW6sb+W3bL8CWp+yBxox15VgarXIkCItVBODxwJTgj1pFmcKITIAEy3CZNh/8zkzzcvGqs7mmhTW+hVs4QZ7R8YaVzEQC+VqgWVGRksWSebZEUKDW0gU1TIHzQMprOpJwcHtPs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811724; c=relaxed/simple; bh=A+gsmRHhQ65EGjIdwCREM1GXzXS4uN/8v+W2J6N27oU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=paq595J5jvDiP38m4tYOmopvdUuDIbfK50E3gDkVkjhewGvwPbAhajq/v6sVX17Ukm2fBkqLMjeNbpLvhs3rdIysxfgg7BvylOw7JOsux4kb72fFcdmtA38k3jG3oMUeDrQDiLR1YLEn56vtKVSb1VBtkKbeu2KJjG99Bj8Tm98= 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=KczF5rZ0; arc=none smtp.client-ip=192.198.163.17 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="KczF5rZ0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811724; x=1817347724; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=A+gsmRHhQ65EGjIdwCREM1GXzXS4uN/8v+W2J6N27oU=; b=KczF5rZ0oJlcjGfDPH27xhwkHbT0ygJjw7vy3hpoVkMTegcPBPndlwrJ i6sD6ktwyC15BViI38MunyD8+71GzPXv1RAThG0/1+G0IuwB4+POgqvpd mPJ7wn6nAg5AxtrRI88czzX/+mzb/vi0jMEM0FcwLzyY86mmXNVKbvG2n zbyPkOtkZWkmYyR0SQyJ8ULvC8uqxaIbwanGE+ViWq6Vdw89CJkAKKCnN qNlSLu+TAHreUxIYyHkPFCdocQLSelZKwv0fPlFgYNWi3F0ONvkUg306i pbT/tjcla/8cMcxjhlZ7vuUPr0EB61SAbHyn2I5WOkV8lAnURATvmKDHP A==; X-CSE-ConnectionGUID: DwjPwiWuQCa3D0QrJEQGTw== X-CSE-MsgGUID: 2//mmVpxTQq37/PmrznRZg== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231285" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231285" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:43 -0700 X-CSE-ConnectionGUID: 2Zmy5qyiRReDhKieKlfDgw== X-CSE-MsgGUID: DJUAhbueRUyGR87sJNYdiA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587515" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48:41 -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 09/20] iommu/vt-d: Use dmar_can_force_on() for platform opt-in Date: Tue, 4 Aug 2026 10:37:03 +0800 Message-ID: <20260804023714.3080506-10-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 D439A41D11D for ; Tue, 4 Aug 2026 02:48:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811727; cv=none; b=rxXz727xrBkjhm7DjjVBdYxuQiDM32A6h2c56xU9/794xE+LLMiKeutFvejC7JjVb5Qau7Klfo+NFQPqPRECp324/J51Qiic+fh7ZZq6ZkppEe+HAU/5pdFkveDi6D2gMQQUfKy5rpnBtIfwVtxiEtjF76lh+glx4vZZkPEOaBM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811727; c=relaxed/simple; bh=8FoqMs3ZYEeu3bLuLfkxhhxNSLw1by1xUZ5wqDUZOY4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=A80yA+MDO40WGglfqXNMusGjngcmhthOnRqUSS8gsowohoSVVGjNVe74W6FaN2h9X1EUQwZugPUayHKWIJAT76YPBXJA7OIMQdLxsb8j6Y/Aj6YX6SVPrBc5qgS3wzlGy2ztcM4umkq4SoxbJSfD4AqNaFej3Swwfg9CodjHfrk= 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=Kpm/4f0a; arc=none smtp.client-ip=192.198.163.17 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="Kpm/4f0a" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811726; x=1817347726; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=8FoqMs3ZYEeu3bLuLfkxhhxNSLw1by1xUZ5wqDUZOY4=; b=Kpm/4f0aP9g4frC2uSB0Vn0sqVqQDz470huWptb6W8LTQ85SqsnFvC7q tarpvVXFaDagXzQ93DAaaHZX48rZtpYR86sN2+ZoonlsYJQ9mhPOLTeRZ O6mENm5bSBDaCeZYat5DP+qNhE799nOA9sP+iz3bX55gr6XbJGbA915Wr rtbn/gluKhy7K3J7fv6s9CKr80gxpOLaIsMJopaUOgDmkdF5Gvx/Zarn7 zbZo+FcgYkHjoOoYwr523tA7lLri9Zhj7MtRemzY4PXN9UP7oHt71oc/s GruqagUdug4uK3Ge5WG6k3eD+ct2YkUfaLnhON+jmI8a8DNePZYR81Ihe A==; X-CSE-ConnectionGUID: LwA2AaU1QVC6GC9UitgEPw== X-CSE-MsgGUID: j6qcHMf5RTSCGcloJFLO5w== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231295" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231295" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:45 -0700 X-CSE-ConnectionGUID: KXHweeTHS+OSrL9TjCG9pg== X-CSE-MsgGUID: sic2wBSwSOGiDNKZUNeJiQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587527" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48: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 10/20] iommu/vt-d: Call dmar_can_force_on() for tboot opt-in Date: Tue, 4 Aug 2026 10:37:04 +0800 Message-ID: <20260804023714.3080506-11-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 DBA064137A2 for ; Tue, 4 Aug 2026 02:48:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811729; cv=none; b=jRCZApXgLfTuWJBH0TdQjdkr3Ega4omnwEKCZFWTvNZ0j/Pziv1DSb0giwEHpHzfz2EFhtXRvvyJPvjfyfFqaZk5efLh4psAgq/YnmpHY6J6b1uZpTcgrX95UOyiSBh5XvodYb0jw4sjBzUB9+o2OZMjB6ubsZ+CgnwpWJ8DfTs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811729; c=relaxed/simple; bh=dlVfOaW2BcS/8ZscA+AC93RlpoSyCVyt3w8eLMCO4GM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Fn1DEFJlv7nIhIALnvs6jr+PyA3eqPLg2bzx5GruRV5Z+hmdaFHTolCXvaKhO1CXDBwTC6P9C/Js95QGOGuLkdto/Fdjyzp8V35DUjxUPdEn/Ooy/Hs8jmdHdbC3pRb/edNe6yKXpYGjO+Uf2LjOkmtkuPSj09BL7JFR8SSZ+sw= 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=nmdxkPzk; arc=none smtp.client-ip=192.198.163.17 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="nmdxkPzk" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811728; x=1817347728; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=dlVfOaW2BcS/8ZscA+AC93RlpoSyCVyt3w8eLMCO4GM=; b=nmdxkPzkXv63TA837GVGcxAiLu90kUqJpEAN8+PCHW2/tvEWEasa5OHF QJoXNrYLK3U2pt2k18xjldGgk1Hq9BAFOUTxKjMgtrX7/6XR7I15IDHu8 tj37Pk7GW/cHTlCH4U7I4xHJgOctu3tUGLgh/eipMLa0JRpSM4u4psUGQ qhCeCzhRaq7/HSjg5+6200b31j3fJ8Hvhi1vk03sRqqV4fNSu5xWk84AV uEFoqauTUxZqF+NhEcP3kJ4TfgGMVEqiZvTZm7FgeiJYjA0JdpSuC+gEJ 4ZGUB1x42UOWLkclQFNwYSFRI6aBy7vyBWxR9malSf/l4TpvVyBII2Ezo Q==; X-CSE-ConnectionGUID: j+LUWDVkTHGGl0yh1GZYCQ== X-CSE-MsgGUID: lbkvb5e4Tu2vz+J9WqOhUQ== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231305" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231305" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:48 -0700 X-CSE-ConnectionGUID: GDGwrFKoRryF//COmZEhuw== X-CSE-MsgGUID: JERbT/2YS/2712Zz25Od3Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587538" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48: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 11/20] iommu/vt-d: Remove the 'force_on' variable Date: Tue, 4 Aug 2026 10:37:05 +0800 Message-ID: <20260804023714.3080506-12-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 B6DFE41DDE4 for ; Tue, 4 Aug 2026 02:48:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811732; cv=none; b=OjCCvpfcQgZubUZnkU1O8G2gsSU2SipxSoZfmx9VSsMn8WBKhDzOehMiBO3Zrb5sIrYB0NX1SWgYHGqDqF24m+D/++yfZLgfJq45CR4JrPmUx2CZsPWofIxtGVSDEaOtZnUtK8danpR2akM82TEcV7NBmh4FyxKgxFEYw707rZc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811732; c=relaxed/simple; bh=I0opl1w8B2GbMLseY7HCMG0uR/eGIL6O6uLirKXdHBI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NmM0LKA1RCm7dArKGyD255QxQc9ANQJD95Ud5ZSAXKDcdlusfmFwQpy4RA/9bJjkSXvPnflv8PGt1YbPyNLupz9EMNhL74PXee9lowW4Ivsn0dOF6Hr7lPbZc2JUpLmEZQVNdDk3eLVTmNdBEuNSyon+No2IDMb6GHQvR4Ba7D0= 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=WoHJ/58L; arc=none smtp.client-ip=192.198.163.17 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="WoHJ/58L" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811731; x=1817347731; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=I0opl1w8B2GbMLseY7HCMG0uR/eGIL6O6uLirKXdHBI=; b=WoHJ/58LHa4yNYmW/KBzHf7O7UhqROmU/K/RLdFwXqXtiPZRCvCrRqP5 N0wrkaWIhFzZNIU7sec9Eht40fgkva+42PYs7KEJqSjO77EwHITKilBrR vsTS2jwMOL25QOYMUvVknPwYOqz3Tl56D5afLE3WBAuRKnkANRN9gTFS4 Jb6Cit5/CRq8EV0WLaWy3VOFfe7ggUzg9Zy5BwJbsdgm8F/TJM6PK2j30 QvVeOBTUJCvbb2p6ohHU6Y9KSHb1AXsb3W7yQVL3HLfMqEAjyeVVGbaB2 zLST3Jo3qWDh7uB2EQj297SRkVAflhp7z8729J7y6OohHBk0T0RRyCWUb Q==; X-CSE-ConnectionGUID: 0oHsIYPpQma+nURcHSkjig== X-CSE-MsgGUID: NeXSzjNjQZ6aL5RxKQLswg== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231316" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231316" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:50 -0700 X-CSE-ConnectionGUID: Ma5gFujNQ1q3dYTrtiz8wg== X-CSE-MsgGUID: htWB2DaUQQW3Pqxa14xdlg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587553" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48:48 -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 12/20] iommu/vt-d: Remove dmar_disabled Date: Tue, 4 Aug 2026 10:37:06 +0800 Message-ID: <20260804023714.3080506-13-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 A3FFF41F365 for ; Tue, 4 Aug 2026 02:48:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811734; cv=none; b=hmer2YQqEJ8QM8N2RdGkdBqy7wnh26YSihS4cLFt2ygeQVaPMXuxy3ZMusjRcAhmsNbspXbmiUbl/wBt4Kx4MSganqkKKc8+2k6Y/qvwYJWkGN3xhMaZFf+WeIdXWeBvwU6ttNP1+IfaHQRAGcPbJuZJ9EInjDF6jXMf6QXuHPs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811734; c=relaxed/simple; bh=ofazySFC81vyyWifIxKn03mdBwsTstjvWNV/8XW81E4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=P50mR76f4rZBujxjR5vfxqvqc10pAnfEcFHfNKhBNYY5BJMEYZ4DGnRVCJxnC198QFyzk4G2+LfxVQ1yhPiBr+ffmQbt/5mA1x7pt/Os/eij/F98gRTi8qYj2C2LjSw0F6UuX18zE8H6mWSmLWNYryKPxytCnKSjnK+ipSnlb1Q= 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=C9VOBpKI; arc=none smtp.client-ip=192.198.163.17 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="C9VOBpKI" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811733; x=1817347733; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ofazySFC81vyyWifIxKn03mdBwsTstjvWNV/8XW81E4=; b=C9VOBpKIV6/i0BVrxsiIAeg3FBcWjeWjl7mM9WYMpKQJdfSSUQIGd8La /b/K0lP+lEErFeQrSbldJ4JVPpVll0NISZ4zUgFaWd86SWaw6bG1uQ7kl kOJuTgtPTIyGBw+XSe5Uqo6V1VLoEnI2VV2fy/ZRE692uMDtEXqASSltF eNLfgiP1su4AH2sXqp/dMVrrSnI2zYTwsb3Hg8WKAyKStt+41xXtJCFnq WZqPfkeqmRj5Waoz4FJGAr36dy3Pkad9UKfz38Wpu9Kic5dd8EVhzMrOQ J/oJ9w11Blso9qXKI+Vg6EYmSKu0//UXMb+64ygjq8Po8YmnPcASokFjU w==; X-CSE-ConnectionGUID: 8tXGzggmT1GUEKVcqu5Hzg== X-CSE-MsgGUID: dx4qX6SAQRiK7J6lTwcBgg== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231325" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231325" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:53 -0700 X-CSE-ConnectionGUID: ZRI9dbReTjiTOO46WfCqDQ== X-CSE-MsgGUID: ODTCFL5UScuqClVXLNMttg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587564" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48: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 13/20] iommu/vt-d: Support the new DMA_REMAP_OPT_OUT flag bit Date: Tue, 4 Aug 2026 10:37:07 +0800 Message-ID: <20260804023714.3080506-14-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 ECF4C41D223 for ; Tue, 4 Aug 2026 02:48:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811736; cv=none; b=KWSAH0U7YShmLp/YqePq0rcJFw8bsolqoG2+CpfiG5/iTZnA+zkE0Z+utIUp+7jLWmg86EXqnLfYREvylegPIegrvHwk6tlsyZn98bV+z79YLKA6mwBe7vtxcrkAkUkRhm9GNvLNTk5TYGd6HADwSaFyU+GDTxqQLmHxjwzp4g4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811736; c=relaxed/simple; bh=bYxhmqmIFX9Vs3YJLdvrfZ/i13mZ7a4GJErjKqVa80A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sMU2q1jyIstCy4PsyRqbwFcDvss02pK5GZhpj3EGPVAXuZVpIBm1KAFaypMxLlZs4L8IF+0/5mMx/o7vHSJnFBxhYH8IZsugtAddcDbU17xFtoAYhEJUuBKjQhKxPf0Wc6jo+HJVSOAe8r8yZShMxixTSeMczHTdHNCeA+GOhMw= 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=iBnD2vwg; arc=none smtp.client-ip=192.198.163.17 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="iBnD2vwg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811735; x=1817347735; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=bYxhmqmIFX9Vs3YJLdvrfZ/i13mZ7a4GJErjKqVa80A=; b=iBnD2vwgf6Iq5iEAkhvG2BopobLmNxa0p3gMAR5cbfKG0zTpOcb1SIa/ 2aY0tuGW6Qrlw0CdLwkwKLjxELrP+ugt7VKdyDCFDBZXvTlmr8xUTEu1r JBUSKS+wTWuXqVpTx1sroPpJdrknvoKr+euQxZ+73+uMyeAgFqM/Tk+PJ k5qKaSMmroOsUqmt8T6AdYUZDEx5GrQgKZCkB4vPvbYrAxduILXStHb6H JzMUvR1VrElP0q55l22P8nvCskovgicREgcBi4I0yRpCGM80QOxyqSWk8 wfz63NdCsVZtwLNkxcXBkdju8Uz/RtU4M5D67j3DgDfpzSXY7eD+JEr8y A==; X-CSE-ConnectionGUID: BCfuRWFGSVyr6QmU+ZaLIg== X-CSE-MsgGUID: l6hhxYieTRWW0rfkRrgKwQ== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231333" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231333" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:55 -0700 X-CSE-ConnectionGUID: J48bjZ5VT/ev0XZHKw4CvQ== X-CSE-MsgGUID: ayQfe9fhQOGNf+DEnL7NQw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587576" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48:53 -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 14/20] iommu/vt-d: Cache max domain ID to avoid redundant calculation Date: Tue, 4 Aug 2026 10:37:08 +0800 Message-ID: <20260804023714.3080506-15-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 1C402421EF4 for ; Tue, 4 Aug 2026 02:48:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811738; cv=none; b=lom9FA/MB7kMMiFVHCx5HZoSiBcAKEpAAyZBaw1ZSIQY/7HtkWR/b+rogNxX2zUd4BG/fbyBKgpCXUbRYwNf0L82tAeFVk2FoGvNXgYe2h5mYTzlfhAwBwx4Tm8bcP5YYx7KzJjL7Y2QxZ+gss1/txiBGJXg7wm2EEzdnfN11OQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811738; c=relaxed/simple; bh=9NljmWmOa7zf85w1KhZzM5Q3pk7MPOLgw1HR0hX9Rhw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CVUM0dQq6DgNi8oC06XjgpXHMZoT0m3yj73dh2FJpxWOXUQWBw8AYBMFQhncDQOQVhxdze6UVdoOfSkctoKKMqsmnAoAdBFadv/1NytnbAid5MoPVYZfuoF4YzES8nMUfgj5p+QAz4BOI2VNM6qULZZC2Y7gvbob8In3y2PoIwA= 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=jxQ+dPNZ; arc=none smtp.client-ip=192.198.163.17 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="jxQ+dPNZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811737; x=1817347737; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=9NljmWmOa7zf85w1KhZzM5Q3pk7MPOLgw1HR0hX9Rhw=; b=jxQ+dPNZ2RyWKOHemPqczUUOX+VDwQbwKxqLbm8EA6qsAugi4XwVkrrA pcpk/uU5g9+mDMyUclrhN2TiR9uuSf2ae7QsplZI6YuDApemL9xa3h+RV gZZBHmQbdfabd9g1i4Eul0+u+CKJMymNWrYpSgrJGnR2QNjq9+7QKDd9R nyzExAkXvezhGuyFEZHvgFRxycdrlF3OQ2F2uzAV+IkUamVAyMBRU9qyc 5E3QiyZNuIULAR628bAPyVfMw05v/0JqVvHaEWq+cxwOmzgW0uK4VJqXS 2IwvjkiuX5xVRk3BTAYyDVUJQa066/KB4oSga+ozPnHubyWSRl/UhAMJs w==; X-CSE-ConnectionGUID: 3cSw79LiRUaZEKg9tAmj+Q== X-CSE-MsgGUID: /W/+9HraQbemFSdxBkwiYQ== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231342" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231342" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:57 -0700 X-CSE-ConnectionGUID: lSQ4U9u1S4WODt/sl9d+mw== X-CSE-MsgGUID: 7xgenynzQZe0va3hkDWYmA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587587" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48:55 -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 15/20] iommu/vt-d: Fix copied_tables bitmap leak on error in copy_translation_tables Date: Tue, 4 Aug 2026 10:37:09 +0800 Message-ID: <20260804023714.3080506-16-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 6E451425860 for ; Tue, 4 Aug 2026 02:48:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811740; cv=none; b=kgr5b9BytyhH29Sgghn+npD24s8ebf+fBc3HyQBIHu/2lHwrL1KSvP6x/G6peJI6+EP8kgP1TC7HsXySzTgQeiaD6OnvHn3arC2ppnhsJQoAr6dX/wils6njBjpMaY6tGwd8wLsURVWD5kCDsriw0jXr96GYvnrU+OfWHMeTmM0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811740; c=relaxed/simple; bh=8LtPkxcWpS1GNxDar8jMK/2ygN+Y4aUhB+dGyzNsvAQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Cx86lz2XUj0gTrcKpsv2MjS1pfI4nPDxQe8D0hb6vw3aNRvpd03eLvzy56c4YrKuPZ91yeDJKzM/uh8OWthm/Ln+Wf/KwAGx2kT7mZ77wElFOufNlqTMfwSieVVY94O5J/rZ+zuWR9+Dj/R49zdHhipJO3NkbWPiMkz0MZN4p9I= 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=aD4TTYWd; arc=none smtp.client-ip=192.198.163.17 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="aD4TTYWd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811740; x=1817347740; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=8LtPkxcWpS1GNxDar8jMK/2ygN+Y4aUhB+dGyzNsvAQ=; b=aD4TTYWdSqlCOZrvYmdfrSOuG6iGDAFEcbqJNkag8fG+LPzHaQ0ZNLHa Vd84lnfZVASWPZI3nR+VeVp9eKP0JRYUyek8Wt2CkONEcytDisjmgnmJW rlh5hJldH+cpbTKoOYoJbo3JRluuMxzkw2guf3e5gWokasNBCeVI/2XVe 28w9yDtgWt2SCtDvnv3C1PwP2d/mj+Lb5qJNhbmJ8cZr5zkORMCJMHvs5 b5RM9bvNFoFeAbaIb6G6pCsYzqJyZA6S68eDWCGcr6QfKgDQQ/1uL96wD db4t7/pEoIWzhkxofbeaAvEI4q8SzwFnXjtYy5nqi/cfZL8W+81tPQ53h A==; X-CSE-ConnectionGUID: EHyp8D8XRXqYeMaqm4nY6w== X-CSE-MsgGUID: lfF+PAayQvejWIYD5xISlw== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231354" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231354" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:48:59 -0700 X-CSE-ConnectionGUID: JukJX6YcTNOEt5sDde/GeQ== X-CSE-MsgGUID: A3PLbM/UTJWe4w2SyTsLLw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587602" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:48:57 -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 16/20] iommu/vt-d: Fix shift overflow in qi_desc_dev_iotlb_pasid() Date: Tue, 4 Aug 2026 10:37:10 +0800 Message-ID: <20260804023714.3080506-17-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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" Callers request a full Device-TLB flush by passing MAX_AGAW_PFN_WIDTH (64 - VTD_PAGE_SHIFT =3D=3D 52) as @size_order. Two shifts in qi_desc_dev_iotlb_pasid() are not prepared for a value that large: unsigned long mask =3D 1UL << (VTD_PAGE_SHIFT + size_order - 1); ... if (!IS_ALIGNED(addr, VTD_PAGE_SIZE << size_order)) The first evaluates to 1UL << 63. On 32-bit builds this is undefined behaviour; in practice x86 masks the shift count to 5 bits, so the expression yields 1UL << 31 and ~mask becomes 0x7fffffff. That value is zero-extended when it is applied to the 64-bit descriptor, so desc->qw1 &=3D ~mask; clears qw1[63:32] as well as bit 31. The ADDR field, which had just been filled with ones to request the widest possible range, collapses to 0x7ffff000. As the S bit remains set, hardware decodes the least significant zero bit of ADDR and invalidates only 2GiB instead of the entire address space. Device-TLB entries above that boundary survive the unmap, leaving an ATS-capable device able to keep accessing memory that has already been freed. The second shift, VTD_PAGE_SIZE << size_order, is 1UL << 64 and is therefore undefined on 64-bit builds too. On x86_64 the shift count masks to zero, IS_ALIGNED(addr, 1) is trivially true and the sanity check silently degrades into a no-op. Compute both quantities in 64-bit and clamp @size_order to the largest range the ADDR field can encode. Capping at 63 - VTD_PAGE_SHIFT keeps the intended "flush everything" behaviour: qw1[62:12] is set, bit 62 is cleared as the size indicator and the S bit is set. The non-PASID variant qi_desc_dev_iotlb() already uses 1ULL and is unaffected. Fixes: f701c9f36bcb7 ("iommu/vt-d: Factor out invalidation descriptor compo= sition") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260623060122.3796325-1-guanghuifen= g%40linux.alibaba.com Assisted-by: Claude:claude-opus-5 Signed-off-by: Lu Baolu Reviewed-by: Samiullah Khawaja --- drivers/iommu/intel/iommu.h | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index c00f44db0020..8a59c7c9d0a6 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1105,12 +1105,20 @@ static inline void qi_desc_dev_iotlb_pasid(u16 sid,= u16 pfsid, u32 pasid, unsigned int size_order, struct qi_desc *desc) { - unsigned long mask =3D 1UL << (VTD_PAGE_SHIFT + size_order - 1); - desc->qw0 =3D QI_DEV_EIOTLB_PASID(pasid) | QI_DEV_EIOTLB_SID(sid) | QI_DEV_EIOTLB_QDEP(qdep) | QI_DEIOTLB_TYPE | QI_DEV_IOTLB_PFSID(pfsid); =20 + /* + * The invalidation range is encoded in the ADDR field, which only + * covers bits 63:12. Clamp @size_order so that callers asking for a + * full flush (e.g. with MAX_AGAW_PFN_WIDTH) do not overflow the + * shifts below. The clamped value still spans the whole range that + * the descriptor is able to express. + */ + if (size_order > 63 - VTD_PAGE_SHIFT) + size_order =3D 63 - VTD_PAGE_SHIFT; + /* * If S bit is 0, we only flush a single page. If S bit is set, * The least significant zero bit indicates the invalidation address @@ -1120,7 +1128,7 @@ static inline void qi_desc_dev_iotlb_pasid(u16 sid, u= 16 pfsid, u32 pasid, * Max Invs Pending (MIP) is set to 0 for now until we have DIT in * ECAP. */ - if (!IS_ALIGNED(addr, VTD_PAGE_SIZE << size_order)) + if (!IS_ALIGNED(addr, BIT_ULL(VTD_PAGE_SHIFT + size_order))) pr_warn_ratelimited("Invalidate non-aligned address %llx, order %d\n", addr, size_order); =20 @@ -1136,7 +1144,7 @@ static inline void qi_desc_dev_iotlb_pasid(u16 sid, u= 16 pfsid, u32 pasid, desc->qw1 |=3D GENMASK_ULL(size_order + VTD_PAGE_SHIFT - 1, VTD_PAGE_SHIFT); /* Clear size_order bit to indicate size */ - desc->qw1 &=3D ~mask; + desc->qw1 &=3D ~BIT_ULL(VTD_PAGE_SHIFT + size_order - 1); /* Set the S bit to indicate flushing more than 1 page */ desc->qw1 |=3D QI_DEV_EIOTLB_SIZE; } --=20 2.43.0 From nobody Fri Oct 2 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 83877429CEC for ; Tue, 4 Aug 2026 02:49:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811743; cv=none; b=rWOG71G0Lq3BqOG7jx6ifRfOZoBFbpniQdufe8+nZ8QnBP8zKazdOz5OmAnRtfJ1otSxRBb75NjjrVXGrvzgWFKZ7XD7HvLE8LyBFkTnzTdCIQdOSlMDwd65IePBZ5F82Kc+PEksvO2TQZB/3pcqTrvNZhAzYEXDUcbefOgEBWE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811743; c=relaxed/simple; bh=kGVbd9pnieA+4WkKdGphqkjUnjw6m66qlFoy3/Q6/+8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L9HdMCKGqNfEUzrtsgDi/Kl5nJpoS8a/QpFHQKy4sQM15f/YvpHUarPty6hnwQjMPs9nxnoPpvjUe8QnkVoSIAV+deuDMUYnnCfArO0/auTJtYSynV5aZqLWnZ02IU8EDbw4za5XTujn18/bP+lt6T1056A7rchAeeqM38wLWL0= 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=abFsZllM; arc=none smtp.client-ip=192.198.163.17 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="abFsZllM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811742; x=1817347742; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kGVbd9pnieA+4WkKdGphqkjUnjw6m66qlFoy3/Q6/+8=; b=abFsZllMEbBFz+E+CQuxSTE2D9HMPMroMfzzEnZPXXsZ8DE/ig1NkyId KxD2uGr2ioHMoVHgbLFvpPHzt+RVXSgKEExrX6HwpvuPbEAI5Yat8eyTI UB1NjbSLVe+FTBS/z8cUHXSGPs9V+fSVqG8c2oU+Jy6IwkTaK1YnDS/FL k+6qOTNmZNMaAh4R0HYBfkswKmufsOxnf6qmSJHEGGXAcng5UZkdS2t9T qeD7CL4KVin4IexL5TkUGNcr0sIEBZ5ooknbv/md3bKBJZpzdgBvBa87a r1PDpucs34/MHQnk+4v0x2HphENl8KqwPtJwF6943ZJxQgAd9A3BZyA7g A==; X-CSE-ConnectionGUID: 4UgKPdXuS/ShM9MP10qk/g== X-CSE-MsgGUID: 7FZ3FfQlRmmkJ8+ldD1y/w== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231365" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231365" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:49:01 -0700 X-CSE-ConnectionGUID: MzVLTTsOTo6mh0p81YQpVQ== X-CSE-MsgGUID: B0P+Oxq5R+KLRMdq+9qeBQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587615" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:49:00 -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 17/20] iommu/vt-d: Clear Present bit before tearing down copied context entry Date: Tue, 4 Aug 2026 10:37:11 +0800 Message-ID: <20260804023714.3080506-18-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 DCE6341DE1E for ; Tue, 4 Aug 2026 02:49:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811745; cv=none; b=qC7y/A7aQant2eguxxIQk4hyIWc4lD5k4K4lNl6uJWbDh8uVF+BcfF/dVtozbfvj9fD5XuajrIphu5mmqkf4dZPQCzKFmw6BE/07icqvu8M7BQJVWUV/be0IqXtTLx/lR89fLVWNUyyDiilaNLNgF9jgx3luGbKeoBSAFl1eCD4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811745; c=relaxed/simple; bh=0hEoNuRKl+qs3eW7LpOd8AxqJYyeaodBDnjTITybW1k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HmsCW98HXpZ6ndcSyUVb4Dyzu4zcF4/Wp/C6mmTMy1bhGfW9JOmztXUa+6NJjtObx9iTj7XK+A8TbHNnOvQM0XfduEnXMeXn4jBR+Z/m2xUuIei66VaxuBJmL3eAtkwuycFQFOzTdH/2dxIJ+SPj9EzsL+Mpp31lhjCdjdzZkUM= 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=ZEVaGkb2; arc=none smtp.client-ip=192.198.163.17 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="ZEVaGkb2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811744; x=1817347744; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=0hEoNuRKl+qs3eW7LpOd8AxqJYyeaodBDnjTITybW1k=; b=ZEVaGkb2zJEuj8Qm565xll8yDduH3BtZoB0TeB3GFtHacsnBhQhkAzwB MSQqydtLo7pIxBozk6b0kvgFnELvMFir9UOrsjSFLkJJEkjfG723B4tv5 rjhDzF42P70I6Ga/nMd19wAMBRo6p6Bq52H4mDxRFLnEw6n8Hzb5KbqnI C9IfPDkDJ9H1xyaj2c8xS3iL7QANWSbszbCkhZjNBT74cmSfP01ccSrrx jFLmLX/Syr4uCRQxTaNE0NcgjQcjJ4X/M5JJfZPApg281K4wcgvk7dBqL IWXeQsHI3azjPqURiA927rfZakEQ7ekuvDHOq9iDSQcmE56IBWUWjWx9D A==; X-CSE-ConnectionGUID: u2R53wW8R86Yh/AlYT3edQ== X-CSE-MsgGUID: ohz3VcE5TXuj/cnp/LlxZg== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231374" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231374" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:49:04 -0700 X-CSE-ConnectionGUID: 7EdnSyraSOyqfLcAIsHl1w== X-CSE-MsgGUID: SAhFNJ2xRsa9FUNkbG9Zlw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587632" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:49:02 -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 18/20] iommu/vt-d: Fix iopf_refcount leak on RID domain replacement Date: Tue, 4 Aug 2026 10:37:12 +0800 Message-ID: <20260804023714.3080506-19-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 13BA5430781 for ; Tue, 4 Aug 2026 02:49:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811747; cv=none; b=b9tab3Ix5M+ZNS0EgthyZ3rN+yK+EzbU0L9qjsF+7SKk22y1YfmbIhCe6BZ5w2HcQsqAYMy1U92jvjMWRGzpaZaIHWxWt2JVrPQLnQPGdK4qJBigxXnt+9H27AKjonEg3tlC6nu4Mz9/VD3aHrQloBc+Nctp4qF7tA0QhYc7w/s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811747; c=relaxed/simple; bh=pnwJe36D1sL/gNEszmY3UecgU2zT9dRDC3/tQgH4P6c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mN3USMV6AxvKp6NxE5gfaq+FH158ve2mkIPoqcczjhsqGUHF7skE/5BHOMJlOg6kdQVzDnXJkPxWDeREUfslgHwL0F2fAEgzM8lUFXbiQqwck6gLjI/jSHvIaAu833Iz0+n6qDtMGK1Eu9bZi3BIkg+9iQucU7yaij70FDLZ95I= 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=Yfbjdol1; arc=none smtp.client-ip=192.198.163.17 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="Yfbjdol1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811746; x=1817347746; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=pnwJe36D1sL/gNEszmY3UecgU2zT9dRDC3/tQgH4P6c=; b=Yfbjdol1hfDrCeqcG5Woojrsge2bqaU/RW/HxwCoMlf3KYCoOxEx+PYq PK8OA7z88Wfen/PRPB28MfUGBT7hCxiCSHauOu7pbi4CRVLWdR/6P4oaQ ZqSvrMJ/2ptEoXZXhOg/YCD9WSWH9I7RT5Ofx+4Rv88zWdnIv2S6ydceB OVfmkkjf71OJkhIh8FyTSjxl6/tQtMfXepx4SWDDpkxZf4Y6N3To9Pnub SLlQXH04/llSrMtGQ0rdgFP1pSoq25C55HtwhMiE8H3VbiF1kEIMmt3qT //IIWrTM1FD46jd+ZqRGmwCPOv8SDlPhymWkez4GfxYWszI8ya+5JTvFE A==; X-CSE-ConnectionGUID: IW7FA+8YQs+PEtRW2Vni9A== X-CSE-MsgGUID: B+m/RgKrQ0OJREBWHBN1ww== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231383" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231383" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:49:06 -0700 X-CSE-ConnectionGUID: d2ixe8DhRsm+bxtHqPRcVw== X-CSE-MsgGUID: FtOQCQoqTYaFlF+btNPIQg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587644" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:49:04 -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 19/20] iommu/vt-d: Tear down scalable-mode context on probe failure Date: Tue, 4 Aug 2026 10:37:13 +0800 Message-ID: <20260804023714.3080506-20-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 07:45:24 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 4A6DB4334DE for ; Tue, 4 Aug 2026 02:49:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811750; cv=none; b=U2lf/jpYXLAqvF32R/1jk3hh7l68G3yUw4Golg1pZ4FcQDLRtUqmdrtbujiYrf6lK28k+Vx+3ZJ0hS5qQ3GAWTscaDKQp9yRVf7/eRmdCh7Cy7pcvzIxnhepVFN1/U++A5aTAnpoDLtzFoNuV6tN0JmxDMAjk8MNQzplwv3ewuU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785811750; c=relaxed/simple; bh=3HfRHapNOd8eFbig6h3On+s2w+9CPPL+mb6DqLlngQY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZZwLSMKDogASLwdglBanAS2nELmHubf0WRpSzC+a5Jlz7tJ6rVmK4YepbSaImyJ/kjhVh7hTTOC0Vh12n24i/AobvHkE3sTKbrDc8q49iKLjGMNvqmn6ks3Qg+M3igC+IPtKEp+xUQraXSrz3ZkLp6p9EHlzHSNhAB3T8K125cg= 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=OJa/65BK; arc=none smtp.client-ip=192.198.163.17 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="OJa/65BK" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785811748; x=1817347748; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=3HfRHapNOd8eFbig6h3On+s2w+9CPPL+mb6DqLlngQY=; b=OJa/65BKbPBwx+jCNZDzvlmCjmi9ddNsCkYzEXojtAxJAZUEgcin/O8v 6Y0TqmAvkhWsJzDBaBG6AeCFDd36VMfPC2+Obvdfk9m8TU/m7Xqp/P7QS ldGxWIqqmLO6eQ3XQrKjnSQRBubxvVoLvUmpQGkiyDD4ScFTIpwX2gQ0J OAiVBSZ5knKxIz27onFHdY5FHuepb1eMVt3WOQwh02/ea83cAM2gigYMr uTt0wPjHeK9fliDPcbtulA4tKmeahauN4pq8L8QO8yDOTtzQmPC2VZ8Z/ PUiWvB7RXALFOK1AoyE4TWD+Edir5yKjzI4M95eDlQrUgx9QOGmNLVOaq Q==; X-CSE-ConnectionGUID: XsGJ04QPSUSR+Pr/zFLVDA== X-CSE-MsgGUID: sy7fFFWOSqW5rs26u3t4dg== X-IronPort-AV: E=McAfee;i="6800,10657,11864"; a="86231391" X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="86231391" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Aug 2026 19:49:08 -0700 X-CSE-ConnectionGUID: +AALB5NWQTWpIyQmAPfYGg== X-CSE-MsgGUID: U/6aMd1pRvCtyuNT0CMnGQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,203,1779174000"; d="scan'208";a="259587656" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa006.jf.intel.com with ESMTP; 03 Aug 2026 19:49: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 20/20] iommu/vt-d: Flush context cache with correct SID when tearing down aliases Date: Tue, 4 Aug 2026 10:37:14 +0800 Message-ID: <20260804023714.3080506-21-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260804023714.3080506-1-baolu.lu@linux.intel.com> References: <20260804023714.3080506-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 8a59c7c9d0a6..7f01620bf3a1 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1249,7 +1249,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