From: Bjorn Helgaas <helgaas@kernel.org>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: jgg@nvidia.com, will@kernel.org, robin.murphy@arm.com,
bhelgaas@google.com, joro@8bytes.org, 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 v4 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Date: Tue, 19 May 2026 14:36:49 -0500 [thread overview]
Message-ID: <20260519193649.GA715262@bhelgaas> (raw)
In-Reply-To: <f6734b9dad0050138676f11ecd14e9db1cf6b697.1777269009.git.nicolinc@nvidia.com>
On Sun, Apr 26, 2026 at 10:54:00PM -0700, Nicolin Chen wrote:
> Controlled by the IOMMU driver, ATS is usually enabled "on demand" when a
> given PASID on a device is attached to an I/O page table. This is working
> even when a device has no translation on its RID (i.e., the RID is IOMMU
> bypassed).
>
> However, certain PCIe devices require non-PASID ATS on their RID even when
> the RID is IOMMU bypassed. Call this "always on".
>
> For example, CXL spec r4.0 notes in sec 3.2.5.13 Memory Type on CXL.cache:
> "To source requests on CXL.cache, devices need to get the Host Physical
> Address (HPA) from the Host by means of an ATS request on CXL.io."
>
> In other words, the CXL.cache capability requires ATS; otherwise, it can't
> access host physical memory.
>
> Introduce a new pci_ats_always_on() helper for the IOMMU driver to scan a
> PCI device and shift ATS policies between "on demand" and "always on".
>
> Add the support for CXL.cache devices first. Pre-CXL devices will be added
> in quirks.c file.
>
> Note that pci_ats_always_on() validates against pci_ats_supported(), so we
> ensure that untrusted devices (e.g. external ports) will not be always on.
> This maintains the existing ATS security policy regarding potential side-
> channel attacks via ATS.
IMO this doesn't really fit in the PCI core. ats.c encapsulates
discovery and provides interfaces to access the ATS Capability, but
the users of those interfaces are all outside the PCI core.
The decision to enable enable ATS for CXL.cache devices is fine but
it's really an IOMMU usage policy, and I think it should be
implemented in the IOMMU core. All the pieces needed
(pci_ats_disabled(), pci_ats_supported(), pci_find_dvsec_capability())
are already exported.
One motivation for putting this in the PCI core was to use the quirk
infrastructure, but this series doesn't use any of that. It doesn't
declare any fixups, e.g., DECLARE_PCI_FIXUP_FINAL, and it doesn't
update any state cached by the PCI core.
> +++ b/include/uapi/linux/pci_regs.h
> @@ -1349,6 +1349,7 @@
> /* CXL r4.0, 8.1.3: PCIe DVSEC for CXL Device */
> #define PCI_DVSEC_CXL_DEVICE 0
> #define PCI_DVSEC_CXL_CAP 0xA
> +#define PCI_DVSEC_CXL_CACHE_CAPABLE _BITUL(0)
This makes good sense, I'm fine with adding
PCI_DVSEC_CXL_CACHE_CAPABLE.
> +bool pci_ats_always_on(struct pci_dev *pdev)
> +{
> + if (pci_ats_disabled() || !pci_ats_supported(pdev))
> + return false;
Isn't this the same as:
if (!pci_ats_supported(pdev))
return false;
If pci_ats_disabled(), dev->ats_cap should be zero, so
pci_ats_supported() should always return false.
> +
> + /* A VF inherits its PF's requirement for ATS function */
> + if (pdev->is_virtfn)
> + pdev = pci_physfn(pdev);
> +
> + return pci_cxl_ats_always_on(pdev);
> +}
> +EXPORT_SYMBOL_GPL(pci_ats_always_on);
next prev parent reply other threads:[~2026-05-19 19:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-27 5:53 [PATCH v4 0/3] Allow ATS to be always on for certain ATS-capable devices Nicolin Chen
2026-04-27 5:54 ` [PATCH v4 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices Nicolin Chen
2026-04-27 16:31 ` Dave Jiang
2026-04-30 21:41 ` Dan Williams (nvidia)
2026-04-30 23:28 ` Nicolin Chen
2026-05-01 23:27 ` Dan Williams (nvidia)
2026-05-01 23:46 ` Jason Gunthorpe
2026-05-02 0:19 ` Dan Williams (nvidia)
2026-05-19 19:36 ` Bjorn Helgaas [this message]
2026-05-19 22:23 ` Jason Gunthorpe
2026-05-19 23:48 ` Bjorn Helgaas
2026-05-20 0:05 ` Jason Gunthorpe
2026-05-20 1:04 ` Nicolin Chen
2026-05-20 14:20 ` Jason Gunthorpe
2026-05-20 17:29 ` Nicolin Chen
2026-05-20 17:47 ` Bjorn Helgaas
2026-05-20 17:56 ` Jason Gunthorpe
2026-05-20 13:12 ` Yi Liu
2026-05-20 14:34 ` Jason Gunthorpe
2026-04-27 5:54 ` [PATCH v4 2/3] PCI: Allow ATS to be always on for pre-CXL devices Nicolin Chen
2026-04-27 16:32 ` Dave Jiang
2026-05-20 13:12 ` Yi Liu
2026-05-20 17:50 ` Bjorn Helgaas
2026-05-20 17:53 ` Jason Gunthorpe
2026-04-27 5:54 ` [PATCH v4 3/3] iommu/arm-smmu-v3: Allow ATS to be always on Nicolin Chen
2026-04-27 16:37 ` Dave Jiang
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=20260519193649.GA715262@bhelgaas \
--to=helgaas@kernel.org \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=jonathan.cameron@huawei.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=miko.lenczewski@arm.com \
--cc=nicolinc@nvidia.com \
--cc=nirmoyd@nvidia.com \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=vsethi@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox