[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260119175826.GM1134360@nvidia.com>
Date: Mon, 19 Jan 2026 13:58:26 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: will@...nel.org, robin.murphy@....com, bhelgaas@...gle.com,
joro@...tes.org, praan@...gle.com, baolu.lu@...ux.intel.com,
kevin.tian@...el.com, miko.lenczewski@....com,
linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache
capable devices
On Fri, Jan 16, 2026 at 08:56:40PM -0800, Nicolin Chen wrote:
> Controlled by the IOMMU driver, ATS is usually enabled "on demand", when a
> device requests a translation service from its associated IOMMU HW running
> on the channel of a given PASID. This is working even when a device has no
> translation on its RID, i.e. RID is IOMMU bypassed.
I would add here that this is done to allow optimizing devices running
in IDENTITY translation as there is no point to using ATS to return
the same value as it already has.
> For instance, the CXL spec notes in "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 word, the CXL.cache capability relies on ATS. Otherwise, it won't
> have access to the host physical memory.
>
> Introduce a new pci_ats_always_on() for IOMMU driver to scan a PCI device,
> to shift ATS policies between "on demand" and "always on".
>
> Add the support for CXL.cache devices first. Non-CXL devices will be added
> in quirks.c file.
>
> Suggested-by: Vikram Sethi <vsethi@...dia.com>
> Suggested-by: Jason Gunthorpe <jgg@...dia.com>
> Signed-off-by: Nicolin Chen <nicolinc@...dia.com>
> ---
> include/linux/pci-ats.h | 3 +++
> include/uapi/linux/pci_regs.h | 5 ++++
> drivers/pci/ats.c | 44 +++++++++++++++++++++++++++++++++++
> 3 files changed, 52 insertions(+)
This implementation looks OK to me
Thanks,
Jason
Powered by blists - more mailing lists