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

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

On 6/17/2026 3:14 PM, Tian, Kevin wrote:
>> From: Baolu Lu <baolu.lu@linux.intel.com>
>> Sent: Monday, June 15, 2026 1:01 PM
>>
>> On 6/4/26 13:15, Kevin Tian wrote:
>>> +
>>> +static inline bool dmar_is_enabled(void)
>>> +{
>>> +	return dmar_state > 0;
>>> +}
>>> +
>>> +static inline bool dmar_is_disabled(void)
>>> +{
>>> +	return dmar_state < 0;
>>> +}
>>
>> The helpers above seem to conflict with:
>>
>> 	extern int intel_iommu_enabled;
>>
>> Can we possibly make the interface consistent?
>>
> 
> Can you elaborate the 'conflict' part?
> 
> If dmar_state<0, intel_iommu_enabled will be 0 as no initialization
> will happen.
> 
> if dmar_state>0, intel_iommu_enabled may be 0 or 1 upon whether
> initialization succeeds.
> 
> they server different purposes.
> 
> or did you mean that the name dmar_is_enabled() may cause
> confusion with intel_iommu_enabled?

Yes, that is exactly my concern. dmar_is_enabled() might be misused as a
replacement for intel_iommu_enabled.

> 
> I could rename it to dmar_should_enable() and dmar_should_disable()
> to differentiate.

That's better. How about dmar_requested()?

/*
  * Track whether the system wants to use the IOMMU based on a
  * combination of command-line overrides, firmware hint, platform trust
  * or secure requirements, etc.
  */
static inline bool dmar_requested(void)
{
	return dmar_state > 0;
}

Thanks,
baolu