All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Kevin Tian <kevin.tian@intel.com>, Joerg Roedel <joro@8bytes.org>,
	Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>
Cc: baolu.lu@linux.intel.com, Joerg Roedel <jroedel@suse.de>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Ashok Raj <ashok.raj@intel.com>,
	Chris Wright <chrisw@sous-sol.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	Asit Mallick <asit.k.mallick@intel.com>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/9] iommu/vt-d: Call dmar_can_force_on() for tboot optin
Date: Fri, 12 Jun 2026 21:57:37 +0800	[thread overview]
Message-ID: <cc8cd5bc-e093-4a95-a68b-ae3ca24944bb@linux.intel.com> (raw)
In-Reply-To: <20260604051540.592925-7-kevin.tian@intel.com>

On 6/4/2026 1:15 PM, Kevin Tian wrote:
> 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, add a panic() in case
> dmar_can_force_on() may return false due to future extensions.
> 
> No functional impact at this point.
> 
> Signed-off-by: Kevin Tian <kevin.tian@intel.com>
> ---
>   drivers/iommu/intel/iommu.c | 11 +++++++----
>   1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index edf01261a41d..ed227de6d0ba 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -2544,12 +2544,16 @@ static int __init probe_acpi_namespace_devices(void)
>   
>   static __init int tboot_force_iommu(void)
>   {
> -	if (!tboot_enabled())
> +	if (!tboot_enabled() || intel_iommu_tboot_noforce)

Hmm, it looks a bit strange here. The core design philosophy is that the
trusted boot environment takes priority over user options. However,
checking intel_iommu_tboot_noforce at the very top means a user
option (intel_iommu=tboot_noforce) is successfully overriding tboot.

Is this an exception? If so, it might be worth adding a brief comment
clarifying why `tboot_noforce` is allowed to bypass the priority?

>   		return 0;
>   
> -	if (no_iommu || dmar_disabled)
> +	if (!dmar_can_force_on(DMAR_FORCEON_TBOOT))
> +		panic("tboot: Failed to force IOMMU on\n");
> +
> +	if (dmar_is_disabled())
>   		pr_warn("Forcing Intel-IOMMU to enabled\n");
>   
> +	dmar_state = DMAR_ENABLED_FORCE;
>   	dmar_disabled = 0;
>   	no_iommu = 0;
>   
> @@ -2566,8 +2570,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 = (!intel_iommu_tboot_noforce && tboot_force_iommu()) ||
> -		    platform_optin_force_iommu();
> +	force_on = tboot_force_iommu() || platform_optin_force_iommu();
>   
>   	down_write(&dmar_global_lock);
>   	if (dmar_table_init()) {

Thanks,
baolu

  reply	other threads:[~2026-06-12 13:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-04  5:15 [PATCH 0/9] iommu/vt-d: Support a new DMAR flag Kevin Tian
2026-06-04  5:15 ` [PATCH 1/9] iommu/vt-d: Fix no_iommu to disable platform optin Kevin Tian
2026-06-04  5:15 ` [PATCH 2/9] iommu/vt-d: Force requesting ACS when tboot is enabled Kevin Tian
2026-06-04  5:15 ` [PATCH 3/9] iommu/vt-d: Remove dead code when CONFIG_INTEL_IOMMU is not set Kevin Tian
2026-06-04  5:15 ` [PATCH 4/9] iommu/vt-d: Consolidate dmar state management and force_on logic Kevin Tian
2026-06-12 11:08   ` Baolu Lu
2026-06-04  5:15 ` [PATCH 5/9] iommu/vt-d: Use dmar_can_force_on() for platform optin Kevin Tian
2026-06-12 13:16   ` Baolu Lu
2026-06-04  5:15 ` [PATCH 6/9] iommu/vt-d: Call dmar_can_force_on() for tboot optin Kevin Tian
2026-06-12 13:57   ` Baolu Lu [this message]
2026-06-04  5:15 ` [PATCH 7/9] iommu/vt-d: Remove the 'force_on' variable Kevin Tian
2026-06-12 14:16   ` Baolu Lu
2026-06-04  5:15 ` [PATCH 8/9] iommu/vt-d: Remove dmar_disabled Kevin Tian
2026-06-12 14:26   ` Baolu Lu
2026-06-04  5:15 ` [PATCH 9/9] iommu/vt-d: Support the new DMA_REMAP_OPT_OUT flag bit Kevin Tian

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=cc8cd5bc-e093-4a95-a68b-ae3ca24944bb@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=chrisw@sous-sol.org \
    --cc=iommu@lists.linux.dev \
    --cc=jbarnes@virtuousgeek.org \
    --cc=joro@8bytes.org \
    --cc=jroedel@suse.de \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=robin.murphy@arm.com \
    --cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.