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

[Baolu Lu]

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