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

[Baolu Lu <baolu.lu@linux.intel.com>]

On 6/17/2026 3:19 PM, Tian, Kevin wrote:
>> From: Baolu Lu <baolu.lu@linux.intel.com>
>> 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