From: Baolu Lu <baolu.lu@linux.intel.com>
To: Michal Camacho Romero <michal.camacho.romero@linux.intel.com>,
Thomas Gleixner <tglx@kernel.org>
Cc: baolu.lu@linux.intel.com, Ning Sun <ning.sun@intel.com>,
Michal Camacho Romero <michal.camacho.romero@intel.com>,
x86@kernel.org, iommu@lists.linux.dev,
tboot-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
Mateusz Mowka <mateusz.mowka@intel.com>,
Adam Pawlicki <adamx.pawlicki@intel.com>,
Pawel Randzio <pawel.randzio@intel.com>
Subject: Re: [PATCH v5 2/2] iommu/vt-d: Disable PMRs and skip force-IOMMU when TXT TPRs are active
Date: Mon, 19 Oct 2026 09:30:44 +0800 [thread overview]
Message-ID: <3a78df93-845a-4432-8aa1-fc4939f4f400@linux.intel.com> (raw)
In-Reply-To: <20261012102211.1739615-1-michal.camacho.romero@linux.intel.com>
On 10/12/2026 6:22 PM, Michal Camacho Romero wrote:
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index 2e3b3ab216f8..ea32730701cf 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -2558,11 +2558,18 @@ static int __init probe_acpi_namespace_devices(void)
> return 0;
> }
>
> -static __init void tboot_force_iommu(void)
> +static __init void tboot_force_iommu(s64 num_of_enabled_tprs)
> {
> if (!tboot_enabled() || intel_iommu_tboot_noforce)
> return;
>
> + /*
> + * If TPR is enabled we don't need to force IOMMU, TPR set by SINIT
> + * ACM will take care of DMA protection.
> + */
> + if (tboot_is_tpr_protection_enabled(num_of_enabled_tprs))
> + return;
> +
I don't quite follow this. The TPRs are disabled once DMA remapping is
enabled in intel_iommu_init(). After that, the IOMMU is the only runtime
DMA protection, which is why tboot forces it on in the first place.
With this change, booting with intel_iommu=off on a TPR-capable platform
would no longer force the IOMMU on. What happens next?
- If the TPRs are left enabled, devices can't DMA into the protected
ranges, so the system is likely broken.
- If the TPRs are later disabled, the measured launch has no DMA
protection at all.
Neither seems acceptable. I may have overlooked or misunderstood
something, so please explain.
> if (!dmar_can_force_on(DMAR_FORCEON_TBOOT))
> panic("tboot: Failed to force IOMMU on\n");
>
> @@ -2584,7 +2591,15 @@ int __init intel_iommu_init(void)
> * Intel IOMMU is required for a TXT/tboot launch or platform
> * opt in, so enforce that.
> */
> - tboot_force_iommu();
> + void __iomem *txt_heap = NULL;
> + struct acpi_table_dtpr *dtpr = tboot_get_dtpr_table(&txt_heap);
> + s64 num_of_enabled_tprs = 0;
Too much tboot internal state leaks into the IOMMU driver. Could tboot
keep this state internally and expose only simple helpers, for example
tboot_tpr_active() and tboot_tpr_disable()?
> + if (dtpr) {
> + /* For the existing DTPR Table, verify TPRs activity status */
> + num_of_enabled_tprs = tboot_check_tprs(dtpr, &txt_heap);
> + }
> +
> + tboot_force_iommu(num_of_enabled_tprs);
> if (!dmar_policy_force_on())
> platform_optin_force_iommu();
>
> @@ -2623,7 +2638,8 @@ int __init intel_iommu_init(void)
> * calling SENTER, but the kernel is expected to reset/tear
> * down the PMRs.
> */
> - if (intel_iommu_tboot_noforce) {
> + if (intel_iommu_tboot_noforce ||
> + tboot_is_tpr_protection_enabled(num_of_enabled_tprs)) {
tboot_noforce should apply to TPRs as well. See the comment on its
definition:
/*
* Skip forcing iommu on and avoid tboot-related kernel panics during
* initialization when set to 1 (via intel_iommu=tboot_noforce).
*/
int intel_iommu_tboot_noforce;
It's a debugging feature to avoid kernel panics during early boot.
> for_each_iommu(iommu, drhd)
> iommu_disable_protect_mem_regions(iommu);
> }
> @@ -2697,7 +2713,24 @@ int __init intel_iommu_init(void)
> iommu_enable_translation(iommu);
>
> iommu_disable_protect_mem_regions(iommu);
> +
Unnecessary change.
> }
> +
> + if (tboot_is_tpr_protection_enabled(num_of_enabled_tprs) && dtpr) {
> + /*
> + * TPRs are enabled. It is necessary to disable active TPRs
> + * to enable DMA usage by the system.
> + */
> + num_of_enabled_tprs = tboot_disable_tprs(dtpr, &txt_heap,
> + num_of_enabled_tprs);
> + if (num_of_enabled_tprs != 0)
> + panic("tboot: Failed to disable TPRs. DMA is still blocked.\n");
> + }
> +
> + /* Release the TXT heap memory if it was allocated */
> + if (txt_heap)
> + tboot_free_txt_heap_mem(&txt_heap);
> +
> up_read(&dmar_global_lock);
>
> pr_info("Intel(R) Virtualization Technology for Directed I/O\n");
> @@ -2707,6 +2740,9 @@ int __init intel_iommu_init(void)
> return 0;
>
> out_free_dmar:
> + if (txt_heap)
> + tboot_free_txt_heap_mem(&txt_heap);
> +
> intel_iommu_free_dmars();
> up_write(&dmar_global_lock);
> return ret;
> -- 2.55.0
Thanks,
baolu
next prev parent reply other threads:[~2026-10-19 1:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 11:44 [PATCH v1 0/2] x86/tboot: Add Intel TXT Protection Regions (TPR) support Michal Camacho Romero
2026-06-03 11:44 ` [PATCH v1 1/2] x86/tboot: Add support for parsing DTPR table and disabling TPRs Michal Camacho Romero
2026-09-14 13:19 ` [PATCH v2 " Michal Camacho Romero
2026-09-15 23:23 ` Sun, Ning
2026-09-17 9:41 ` [PATCH 1/1] " Michal Camacho Romero
2026-09-18 6:45 ` kernel test robot
2026-09-18 7:35 ` kernel test robot
2026-09-17 9:43 ` [PATCH v3 1/2] " Michal Camacho Romero
2026-09-22 10:00 ` [PATCH v4 " michal.camacho.romero
2026-09-23 22:21 ` Sun, Ning
2026-09-30 12:30 ` [PATCH v5 " Michal Camacho Romero
2026-10-05 18:37 ` Sun, Ning
2026-10-12 9:35 ` [PATCH v6 " Michal Camacho Romero
2026-10-27 16:13 ` Sun, Ning
2026-10-29 13:40 ` [PATCH v7 " Michal Camacho Romero
2026-06-03 11:45 ` [PATCH v1 2/2] iommu/vt-d: Disable PMRs and skip force-IOMMU when TXT TPRs are active Michal Camacho Romero
2026-06-11 8:49 ` Baolu Lu
2026-08-07 9:16 ` [PATCH v2 " Michal Camacho Romero
2026-08-07 10:14 ` Michal Camacho Romero
2026-08-20 3:28 ` Baolu Lu
2026-09-03 9:33 ` [PATCH v3 " Michal Camacho Romero
2026-09-04 2:19 ` Baolu Lu
2026-10-01 12:12 ` [PATCH v4 " michal.camacho.romero
2026-10-07 7:11 ` Baolu Lu
2026-10-12 10:22 ` [PATCH v5 " Michal Camacho Romero
2026-10-19 1:30 ` Baolu Lu [this message]
2026-10-29 13:41 ` [PATCH v7 2/2] iommu/vt-d: Disable TXT TPRs before enabling queued invalidation Michal Camacho Romero
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3a78df93-845a-4432-8aa1-fc4939f4f400@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=adamx.pawlicki@intel.com \
--cc=iommu@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mateusz.mowka@intel.com \
--cc=michal.camacho.romero@intel.com \
--cc=michal.camacho.romero@linux.intel.com \
--cc=ning.sun@intel.com \
--cc=pawel.randzio@intel.com \
--cc=tboot-devel@lists.sourceforge.net \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®