Re: [PATCH 6/9] iommu/vt-d: Call dmar_can_force_on() for tboot optin

[Baolu Lu]

On 6/17/2026 3:19 PM, Tian, Kevin wrote:
> > From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
> > Sent: Friday, June 12, 2026 9:58 PM
> >
> > On 6/4/2026 1:15 PM, Kevin Tian wrote:
> > >    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,
>
> user options here refer to "iommu=off" or "intel_iommu=off" which
> opts to enable/disable iommu.
>
> > checking intel_iommu_tboot_noforce at the very top means a user
> > option (intel_iommu=tboot_noforce) is successfully overriding tboot.
>
> but tboot_noforce is to specify the forceon policy on tboot. No conflict.
>
> > Is this an exception? If so, it might be worth adding a brief comment
> > clarifying why `tboot_noforce` is allowed to bypass the priority?
>
> so this is irrelevant to the enable/disable priority part.

Okay, that explains.

The "intel_iommu=tboot_noforce" option is used to disable tboot
entirely, which is not part of the enable/disable override. I suppose
tboot_noforce is only designed for debugging purposes, so it should not
be used in a production environment.

Thanks,
baolu