All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pranjal Shrivastava <praan@google.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: iommu@lists.linux.dev, Will Deacon <will@kernel.org>,
	Joerg Roedel <joro@8bytes.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Mostafa Saleh <smostafa@google.com>,
	Samiullah Khawaja <skhawaja@google.com>,
	Daniel Mentz <danielmentz@google.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	David Matlack <dmatlack@google.com>
Subject: Re: [PATCH rc v2] iommu/arm-smmu-v3: Fix inconsistent ATS state tracking
Date: Mon, 4 May 2026 20:29:29 +0000	[thread overview]
Message-ID: <afkBqQz90OLkY4IN@google.com> (raw)
In-Reply-To: <afkAKlu4nllduGCE@nvidia.com>

On Mon, May 04, 2026 at 01:23:06PM -0700, Nicolin Chen wrote:
> On Mon, May 04, 2026 at 07:33:07PM +0000, Pranjal Shrivastava wrote:
> > On Mon, May 04, 2026 at 11:01:42AM -0700, Nicolin Chen wrote:
> > > On Mon, May 04, 2026 at 04:38:42PM +0000, Pranjal Shrivastava wrote:
> > > I am thinking, maybe the call sites of pci_enable/disable_ats() can
> > > check to_pci_dev(dev)->ats_enabled instead of master->ats_enabled?
> > > 
> > > Then, we keep master->ats_enabled as-is, so detach() can revert the
> > > nr_ats_masters and ATS invalidation entry in domain->invs.
> > 
> > My suggestion in that case would be to update arm_smmu_ats_supported to
> > check if the client is a VF and check if it's PF enables ATS:
> > 
> > static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
> > {
> >     struct device *dev = master->dev;
> >     struct pci_dev *pdev;
> > 
> >     if (!dev_is_pci(dev))
> >         return false;
> > 
> >     pdev = to_pci_dev(dev);
> >     if (!pci_ats_supported(pdev))
> >         return false;
> > 
> >     /*
> >      * If this is a VF, ATS only works if the PF has already enabled it
> >      * with a valid STU.
> >      */
> >     if (pdev->is_virtfn && !pci_physfn(pdev)->ats_enabled)
> >         return false;
> > 
> >     return true;
> > }
> 
> I think that's okay to address the issue for now. But it assumes
> that pci_enable_ats() will never change so it won't fail for any
> other reason.
> 

Hmm.. in that case, could we factor out the 

	if (dev->is_virtfn) {
                pdev = pci_physfn(dev);
                if (pdev->ats_stu != ps)
                        return -EINVAL;
        }

part into a helper and export it? I think iommu drivers could use it?

> > and then in attach_prepare we can add the ats check for safety:
> > 
> >         if (!state->ats_enabled && master->ats_enabled) {
> >                 pci_disable_ats(to_pci_dev(master->dev));
> > 
> > +               if (pdev->ats_enabled)
> > +                       pci_disable_ats(to_pci_dev(master->dev));
> 
> master->ats_enabled is redundant if we check pdev->ats_enabled.
> 
> If we add a gate here, should add to pci_enable_ats() too?

Um.. I accidentally deleted a ` - ` on that line, it was supposed ot be:

-               pci_disable_ats(to_pci_dev(master->dev));

+               if (pdev->ats_enabled)
+                       pci_disable_ats(to_pci_dev(master->dev));

Praan

  reply	other threads:[~2026-05-04 20:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-04 16:38 [PATCH rc v2] iommu/arm-smmu-v3: Fix inconsistent ATS state tracking Pranjal Shrivastava
2026-05-04 18:01 ` Nicolin Chen
2026-05-04 19:33   ` Pranjal Shrivastava
2026-05-04 20:03     ` Pranjal Shrivastava
2026-05-04 20:23     ` Nicolin Chen
2026-05-04 20:29       ` Pranjal Shrivastava [this message]
2026-05-04 20:51         ` Nicolin Chen
2026-05-04 20:40       ` Pranjal Shrivastava
2026-05-04 20:54         ` Nicolin Chen
2026-05-05 16:11     ` Jason Gunthorpe
2026-05-05 20:21       ` Nicolin Chen
2026-05-05 21:23         ` Pranjal Shrivastava
2026-05-05 21:44           ` Nicolin Chen
2026-05-05 22:06             ` Pranjal Shrivastava
2026-05-06 20:44         ` Samiullah Khawaja
2026-05-05 21:14       ` Pranjal Shrivastava
2026-05-05 22:32         ` Pranjal Shrivastava
2026-05-06  9:46           ` Jason Gunthorpe
2026-05-06 20:19             ` Pranjal Shrivastava
2026-05-06 22:03               ` Pranjal Shrivastava
2026-05-06 21:57             ` Pranjal Shrivastava
2026-05-06 22:04               ` Pranjal Shrivastava
2026-05-09 17:14                 ` Jason Gunthorpe
2026-05-11 12:07                   ` Pranjal Shrivastava
2026-05-11 14:16                     ` Jason Gunthorpe
2026-05-11 16:07                       ` Pranjal Shrivastava
2026-05-11 16:30                         ` David Matlack
2026-05-11 16:57                           ` Pranjal Shrivastava
2026-05-11 17:03                         ` Jason Gunthorpe
2026-05-06 22:20               ` Samiullah Khawaja
2026-05-07 20:12                 ` Pranjal Shrivastava

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afkBqQz90OLkY4IN@google.com \
    --to=praan@google.com \
    --cc=danielmentz@google.com \
    --cc=dmatlack@google.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=nicolinc@nvidia.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=robin.murphy@arm.com \
    --cc=skhawaja@google.com \
    --cc=smostafa@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.