Re: [PATCH] PCI: Disable ATS via quirk before notifying IOMMU drivers
From: Andy Shevchenko
Date: Wed Feb 25 2026 - 04:47:11 EST
On Tue, Feb 24, 2026 at 09:41:30AM -0800, David Matlack wrote:
> On Tue, Feb 24, 2026 at 9:25 AM Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > On Tue, Feb 24, 2026 at 09:19:05AM -0800, David Matlack wrote:
> > > On Mon, Feb 23, 2026 at 12:37 PM Andy Shevchenko
> > > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > > > On Mon, Feb 23, 2026 at 06:40:16PM +0000, David Matlack wrote:
...
> > > > > Fix this by disabling ATS via quirk during "early" fixups instead of
> > > > > "final" fixups.
> > > >
> > > > Hmm... Sounds to me like a premature disablement, but I leave it the experts.
> > >
> > > What do you mean by "premature disablement"?
> >
> > On early stage instead of final stage.
>
> Is your concern that applying the quirk at early stage won't be
> effective because ATS will be enabled after early fixups are applied?
My concern that applying this quirk too early may affect something else.
But I'm not an expert in the PCI mysterious ways, I just share my feelings.
> To prevent that the patch adds a no_ats bit that blocks ATS enablement
> after early fixups.
>
> If not that, I guess I am wondering what is your concern from a
> functional level.
>
> > > > What I think about the case, that IOMMU should be probably fixed to avoid such
> > > > situation for all level of quirks. Can it be feasible?
> > >
> > > What do you mean by the "IOMMU should be fixed"? Are you saying the
> > > IOMMU should be prepared to handle quirks disabling features on
> > > devices after the IOMMU driver is notified about a device?
> >
> > Something like this, yes. At least the commit message is unclear why
> > "This fixes at least one bug in the Intel IOMMU driver..." not in IOMMU
> > driver code.
>
> Gotcha. It felt wrong to have the IOMMU driver be notified about a
> device with ATS enabled and then have ATS later disabled. It seem like
> it would add complexity to the IOMMU drivers to handle such a case,
> and would be much simpler to have ATS in its final state when the
> IOMMU driver is notified about the device being created.
Can this be elaborated in the commit message? Then a reviewer will not
have questions like me.
> But maybe Lu Baolu and David Woodhouse (Intel IOMMU maintainers) can
> comment if they prefer to handle this in the Intel IOMMU driver.
I agree that his input may be valuable in this discussion.
--
With Best Regards,
Andy Shevchenko