From: Nicolin Chen <nicolinc@nvidia•com>
To: Bjorn Helgaas <helgaas@kernel•org>
Cc: <jgg@nvidia•com>, <will@kernel•org>, <robin.murphy@arm•com>,
<joro@8bytes•org>, <bhelgaas@google•com>, <praan@google•com>,
<baolu.lu@linux•intel.com>, <kevin.tian@intel•com>,
<miko.lenczewski@arm•com>, <linux-arm-kernel@lists•infradead.org>,
<iommu@lists•linux.dev>, <linux-kernel@vger•kernel.org>,
<linux-pci@vger•kernel.org>, <dan.j.williams@intel•com>,
<jonathan.cameron@huawei•com>, <vsethi@nvidia•com>,
<linux-cxl@vger•kernel.org>, <nirmoyd@nvidia•com>
Subject: Re: [PATCH v6 1/3] PCI: Add pci_ats_required() for CXL.cache capable devices
Date: Thu, 21 May 2026 14:07:34 -0700 [thread overview]
Message-ID: <ag90FlOaljwa0qqU@Asurada-Nvidia> (raw)
In-Reply-To: <20260521205723.GA184317@bhelgaas>
On Thu, May 21, 2026 at 03:57:23PM -0500, Bjorn Helgaas wrote:
> On Thu, May 21, 2026 at 01:34:20PM -0700, Nicolin Chen wrote:
> > +bool pci_ats_required(struct pci_dev *pdev)
> > +{
> > + if (!pci_ats_supported(pdev))
> > + return false;
> > +
> > + /* A VF inherits its PF's requirement for ATS function */
> > + if (pdev->is_virtfn)
> > + pdev = pci_physfn(pdev);
> > +
> > + return pci_cxl_ats_required(pdev);
>
> I acked this before I saw this sashiko feedback, which looks like a
> legit issue to me:
>
> Will this VF inheritance logic ever be reached?
>
> According to the PCIe SR-IOV specification (section 9.3.3.1), VFs do
> not implement the ATS Extended Capability, which means pdev->ats_cap
> is always 0 for VFs.
>
> Because of this, pci_ats_supported(pdev) will unconditionally return
> false for any VF. This causes the function to return false before it
> can ever reach the pdev->is_virtfn check.
>
> Could this prevent VFs from correctly enabling the ATS always on
> feature and leave them unable to access host memory without
> triggering IOMMU faults?
>
> (From https://sashiko.dev/#/patchset/cover.1779304390.git.nicolinc%40nvidia.com)
>
> I withdraw my ack for now until we figure out if it's a real issue.
I did a bit of research here.
The existing pci_enable_ats() checks:
if (!pci_ats_supported(dev))
return -EINVAL;
at the top, prior to:
if (dev->is_virtfn) {
pdev = pci_physfn(dev);
if (pdev->ats_stu != ps)
return -EINVAL;
So, VF must *support* ATS (its ats_cap must be !0) so as to turn
on ATS, instead of relying on the PF's ats_cap.
IOW, Sashiko's comment "which means pdev->ats_cap is always 0 for
VFs" is wrong.
So, I kept the same order in this new pci_ats_required().
FWIW, I also did an inverted version and asked Sashiko to review:
====================================================================
> @@ -205,6 +205,52 @@ int pci_ats_page_aligned(struct pci_dev *pdev)
[ ... ]
> +bool pci_ats_required(struct pci_dev *pdev)
> +{
> + /* A VF inherits its PF's requirement for ATS function */
> + if (pdev->is_virtfn)
> + pdev = pci_physfn(pdev);
> +
> + if (!pci_ats_supported(pdev))
> + return false;
This isn't a bug, but it looks like these two lines are indented with spaces
instead of tabs.
Also, since pdev is reassigned to pci_physfn(pdev) before checking ATS
support, does this incorrectly check the ATS capability of the PF rather than
the VF?
If a VF has its ATS support explicitly disabled (for example, via PCIe quirks
that set vf->ats_cap = 0), this check might bypass the VF's specific
properties and incorrectly return true based on the PF's capabilities.
Consequently, if a caller attempts to enable ATS on the VF by calling
pci_enable_ats(), it will fail because pci_enable_ats() correctly checks
pci_ats_supported() against the VF.
Would it be better to evaluate pci_ats_supported() on the original pdev
before reassigning it to the PF?
====================================================================
What would you like me to do, Bjorn?
Nicolin
next prev parent reply other threads:[~2026-05-21 21:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 20:34 [PATCH v6 0/3] Allow ATS to be always on for certain ATS-capable devices Nicolin Chen
2026-05-21 20:34 ` [PATCH v6 1/3] PCI: Add pci_ats_required() for CXL.cache capable devices Nicolin Chen
2026-05-21 20:57 ` Bjorn Helgaas
2026-05-21 21:07 ` Nicolin Chen [this message]
2026-05-21 21:31 ` Bjorn Helgaas
2026-05-21 21:59 ` Nicolin Chen
2026-05-22 9:19 ` Yi Liu
2026-05-21 20:34 ` [PATCH v6 2/3] PCI: Allow ATS to be always on for pre-CXL devices Nicolin Chen
2026-05-22 9:17 ` Yi Liu
2026-05-21 20:34 ` [PATCH v6 3/3] iommu/arm-smmu-v3: Allow ATS to be always on Nicolin Chen
2026-05-28 15:24 ` Pranjal Shrivastava
2026-05-28 15:29 ` Jason Gunthorpe
2026-05-28 16:32 ` Pranjal Shrivastava
2026-05-28 18:00 ` Jason Gunthorpe
2026-05-28 18:14 ` Pranjal Shrivastava
2026-05-28 18:20 ` Nicolin Chen
2026-05-28 20:04 ` Jason Gunthorpe
2026-05-28 20:39 ` Pranjal Shrivastava
2026-05-28 7:35 ` [PATCH v6 0/3] Allow ATS to be always on for certain ATS-capable devices Jörg Rödel
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=ag90FlOaljwa0qqU@Asurada-Nvidia \
--to=nicolinc@nvidia$(echo .)com \
--cc=baolu.lu@linux$(echo .)intel.com \
--cc=bhelgaas@google$(echo .)com \
--cc=dan.j.williams@intel$(echo .)com \
--cc=helgaas@kernel$(echo .)org \
--cc=iommu@lists$(echo .)linux.dev \
--cc=jgg@nvidia$(echo .)com \
--cc=jonathan.cameron@huawei$(echo .)com \
--cc=joro@8bytes$(echo .)org \
--cc=kevin.tian@intel$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-cxl@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-pci@vger$(echo .)kernel.org \
--cc=miko.lenczewski@arm$(echo .)com \
--cc=nirmoyd@nvidia$(echo .)com \
--cc=praan@google$(echo .)com \
--cc=robin.murphy@arm$(echo .)com \
--cc=vsethi@nvidia$(echo .)com \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox