Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Nicolin Chen <nicolinc@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 18:48:01 -0500	[thread overview]
Message-ID: <20260519234801.GA21369@bhelgaas> (raw)
In-Reply-To: <20260519222335.GK3602937@nvidia.com>

On Tue, May 19, 2026 at 07:23:35PM -0300, Jason Gunthorpe wrote:
> On Tue, May 19, 2026 at 02:36:49PM -0500, Bjorn Helgaas wrote:
> > 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.
> 
> It works like the acs quirks that are in the quirks file, which are
> also arguably only used by iommu too :)

True, although ACS has a lot more PCI-specific grunge in it, including
all the "pci=config_acs" and "pci=disable_acs_redir" stuff.

> I'm not keen on spreading lists of device ids for PCI quirks to iommu
> files, but it would be OK to move pci_ats_always_on() to
> iommu_ats_always_on() that calls the PCI quirk function.

Yeah, I guess it's fair to collect the device IDs in PCI since this is
about characteristics of the device.

If we leave stuff in drivers/pci/, I would prefer that part of it be
named to be purely informational, i.e., "CXL.cache_enabled" or
something similar that would also cover the NVIDIA devices.

"pci_ats_always_on()" doesn't sound right quite to me because it
presupposes the policy choice that IOMMU is going to make; that PCI
function doesn't actually turn ATS on, and it looks like the question
of enabling ATS depends on how the device is actually *used*.  E.g.,
if Cache_Enable is not set, is ATS required?

That raises the question of whether this is the right test:

  +   if (pci_read_config_word(pdev, offset + PCI_DVSEC_CXL_CAP, &cap))
  +           return false;
  +
  +   return cap & PCI_DVSEC_CXL_CACHE_CAPABLE;

That just says the device is *capable* of CXL.cache; should it check
whether CXL.cache is *enabled* instead?

Bjorn


  reply	other threads:[~2026-05-19 23:48 UTC|newest]

Thread overview: 17+ 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
2026-05-19 22:23     ` Jason Gunthorpe
2026-05-19 23:48       ` Bjorn Helgaas [this message]
2026-05-20  0:05         ` Jason Gunthorpe
2026-05-20  1:04           ` Nicolin Chen
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-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=20260519234801.GA21369@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