RE: [PATCH 5/9] iommu/vt-d: Use dmar_can_force_on() for platform optin

[Tian, Kevin]

> From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
> Sent: Friday, June 12, 2026 9:17 PM
> 
> On 6/4/2026 1:15 PM, Kevin Tian wrote:
> >
> >   	/*
> >   	 * If Intel-IOMMU is disabled by default, we will apply identity
> >   	 * map for all devices except those marked as being untrusted.
> >   	 */
> > -	if (dmar_disabled)
> > +	if (dmar_is_disabled()) {
> > +		pr_info("Intel-IOMMU force enabled due to platform opt
> in\n");
> >   		iommu_set_default_passthrough(false);
> > +	}
> >
> > +	dmar_state = DMAR_ENABLED_FORCE;
> 
> I was initially wondering if we needed a lock to protect dmar_state
> here, but since this runs during early boot in a single-threaded
> environment (indicated by the __init prefix), concurrent access isn't a
> concern.
> 
> However, changing dmar_state here does mean that any logic calling
> dmar_is_enabled() before this point will see a "disabled" state, while
> subsequent calls will see an "enabled" state.
> 
> While I don't see a real problem right now, this state volatility is
> something we should document. Could we add a brief comment here to
> clarify this intentional state upgrade?
> 
> 

Okay, I'll add something like:

/* No concurrent access to dmar_state is expected at this point. */