RE: [PATCH 4/9] iommu/vt-d: Consolidate dmar state management and force_on logic

[Tian, Kevin]

> From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
> Sent: Friday, June 12, 2026 7:08 PM
> 
> On 6/4/2026 1:15 PM, Kevin Tian wrote:
> > +/*
> > + * Centralized helper for deciding the force_on policy
> > + *
> > + * dmar disabled states (for DMA Remapping) are defined from stronger
> > + * disables (more negative values) to weaker disables (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
> > + * disabled state less negative than the reference level (if dmar is
> > + * enabled 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=off" or
> "intel_iommu=off")
> > + *   and weaker disables.
> > + *
> > + * - 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 is disabled
> > + *   by build configurations (CONFIG_INTEL_IOMMU_DEFAULT_ON=off).
> > + */
> 
> It reads like tboot successfully overrides the user's choices, whereas
> the platform opt-in cannot. Could you shed more light on this? My
> understanding is that "trusted boot environment" is considered stronger
> than "user choices", which in turn is stronger than a "platform opt-in
> hint".

yes, and this is the existing policy.

> 
> If this is indeed the core design philosophy, would you mind spelling it
> out explicitly in this comment? Making the exact precedence clear
> will help future development follow the same philosophy.

Okay, will add.

> 
> > +bool dmar_can_force_on(enum dmar_force_on force_on)
> > +{
> > +	int level;
> > +
> > +	switch (force_on) {
> > +	case DMAR_FORCEON_TBOOT:
> > +		level = DMAR_DISABLED_USER;
> > +		break;
> > +	case DMAR_FORCEON_PLATFORM:
> > +		level = DMAR_DISABLED_AUTO;
> > +		break;
> > +	default:
> > +		pr_warn("Unsupported force_on type (%d)\n", force_on);
> > +		/* '0' means returning true only when dmar is enabled */
> > +		level = 0;
> > +		break;
> > +	}
> > +
> > +	return dmar_state >= level;
> > +}
> 
> If this helper returns false (meaning a requested force_on type cannot
> be enforced), would it be better to notify the user via a clear pr_info/
> pr_warn in the kernel log?
> 
> Normally, a failure to enforce a requested "force_on" condition might
> mean security or trust implications that the administrator should be
> aware of.
> 

tboot_force_iommu() already throws out a warning:

  " tboot: Failed to force IOMMU on"

I'll add one for platform_optin_force_iommu() too.