From: sashiko-bot@kernel.org
To: "Nicolin Chen" <nicolinc@nvidia.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v5 1/3] PCI: Add pci_ats_required() for CXL.cache capable devices
Date: Wed, 20 May 2026 20:26:42 +0000 [thread overview]
Message-ID: <20260520202643.470AF1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <9e01e6d39deff2bf751da3e1abb43f35a9169194.1779304390.git.nicolinc@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The logic intended to allow a Virtual Function (VF) to inherit its Physical Function's (PF) ATS requirements is dead code. As a result, pci_ats_required() will always incorrectly return false for VFs.
--
commit 0af55683d00886be6357cf5cf0cf3df17b4c4b9b
Author: Nicolin Chen <nicolinc@nvidia.com>
PCI: Add pci_ats_required() for CXL.cache capable devices
This commit introduces pci_ats_required() to allow IOMMU drivers to keep
ATS always on for specific devices, like CXL.cache devices. It includes
logic for Virtual Functions (VFs) to inherit the ATS requirements of their
Physical Functions (PFs).
> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> --- a/drivers/pci/ats.c
> +++ b/drivers/pci/ats.c
[ ... ]
> +bool pci_ats_required(struct pci_dev *pdev)
> +{
> + if (pci_ats_disabled() || !pci_ats_supported(pdev))
> + return false;
> +
> + /* A VF inherits its PF's requirement for ATS function */
> + if (pdev->is_virtfn)
> + pdev = pci_physfn(pdev);
[Severity: High]
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?
> +
> + return pci_cxl_ats_required(pdev);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1779304390.git.nicolinc@nvidia.com?part=1
next prev parent reply other threads:[~2026-05-20 20:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 19:46 [PATCH v5 0/3] Allow ATS to be always on for certain ATS-capable devices Nicolin Chen
2026-05-20 19:46 ` [PATCH v5 1/3] PCI: Add pci_ats_required() for CXL.cache capable devices Nicolin Chen
2026-05-20 20:03 ` Bjorn Helgaas
2026-05-20 20:20 ` Nicolin Chen
2026-05-20 20:26 ` sashiko-bot [this message]
2026-05-20 19:46 ` [PATCH v5 2/3] PCI: Allow ATS to be always on for pre-CXL devices Nicolin Chen
2026-05-20 20:04 ` Bjorn Helgaas
2026-05-20 20:46 ` sashiko-bot
2026-05-20 19:46 ` [PATCH v5 3/3] iommu/arm-smmu-v3: Allow ATS to be always on Nicolin Chen
2026-05-20 21:33 ` sashiko-bot
2026-05-20 22:35 ` Nicolin Chen
2026-05-21 13:44 ` Jason Gunthorpe
2026-05-21 17:44 ` Nicolin Chen
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=20260520202643.470AF1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox