From: Jason Gunthorpe <jgg@nvidia.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
linux-pci@vger.kernel.org, "Kevin Tian" <kevin.tian@intel.com>,
"Lu Baolu" <baolu.lu@linux.intel.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Tony Zhu" <tony.zhu@intel.com>, "Joerg Roedel" <jroedel@suse.de>
Subject: Re: [PATCH] PCI: revert "Enable PASID only when ACS RR & UF enabled on upstream path"
Date: Wed, 11 Jan 2023 09:44:58 -0400 [thread overview]
Message-ID: <Y769WqrbEUPQ3pt7@nvidia.com> (raw)
In-Reply-To: <0da0f213-5d6a-c692-b9f7-9babb40adc96@amd.com>
On Wed, Jan 11, 2023 at 02:38:34PM +0100, Christian König wrote:
> Am 11.01.23 um 14:07 schrieb Jason Gunthorpe:
> > On Wed, Jan 11, 2023 at 09:57:45AM +0100, Christian König wrote:
> > > This reverts commit 201007ef707a8bb5592cd07dd46fc9222c48e0b9.
> > >
> > > It's correct that the PCIe fabric routes Memory Requests based on the
> > > TLP address, but enabling the PASID mapping doesn't necessary mean that
> > > Memory Requests will have a PASID associated with them.
> > It is true, the routine assumes the device will use untranslated
> > requests with the PASID.
> >
> > > The alternative is ATS which lets the device resolve the PASID+addr pair
> > > before a memory request is made into a routeable TLB address through the
> > > TA. Those resolved addresses are then cached on the device instead of
> > > in the IOMMU TLB.
> > We should pass in a flag "device always sets the translated bit for
> > PASID" and skip the ACS check in that case.
> >
> > The ACS check is not wrong, and it is definately necessary for devices
> > that do not guarentee ATS and PASID are used together, we should not
> > be removing it.
> >
> > Given adding the flag is trivial we should just fix it, not revert this.
>
> Well exactly that's the point, adding this flag is absolutely not trivial as
> far as I can see. We need to go through multiple layers of abstraction since
> this is the low level function and nothing high level.
>
> Additional to that the check doesn't seem to make much sense to me.
AFAICT it is the only solution that makes any sense..
> pci_enable_pasid() is called by three functions:
>
> pdev_pri_ats_enable() in the AMD IOMMU driver while enabling ATS. As far as
> I can see we absolutely don't need the ACS check here because ATS is a must
> have.
Enabling ATS does not mean every PASID TLP will use ATS. It just means
that some transactions might.
We cannot do this properly without driver sourced device-specific
knowledge.
> iommu_enable_pci_caps() in the Intel IOMMU driver. This also does some
> handling for ATS, so here we could check the info->ats_supported flag if ACS
> needs to be checked or not.
*groan* this is seems wrong :( Lu why are we doing this inside iommu
drivers instead of in the device drivers to declare they want to use
PASID?
> arm_smmu_enable_pasid() in the ARM IOMMU driver code. No idea what this one
> does with ATS. Here is the only place where the ACS check might make sense.
>
> So even if we have some need for this check this seems to be the wrong place
> for the check since not all necessary information from the higher level is
> available.
IIRC we only have 1 driver using the standard pasid support, so we
could just move these things to IDXD.
The AMD sidechannel thing is only use for AMDGPU so it can just assume
things until it gets fixed to use the standard API.
Jason
next prev parent reply other threads:[~2023-01-11 13:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 8:57 [PATCH] PCI: revert "Enable PASID only when ACS RR & UF enabled on upstream path" Christian König
2023-01-11 9:15 ` Christian König
2023-01-11 10:04 ` Linux kernel regression tracking (Thorsten Leemhuis)
2023-01-11 13:07 ` Jason Gunthorpe
2023-01-11 13:38 ` Christian König
2023-01-11 13:44 ` Jason Gunthorpe [this message]
2023-01-11 13:54 ` Baolu Lu
2023-01-11 14:14 ` Jason Gunthorpe
2023-01-11 14:17 ` Christian König
2023-01-11 14:20 ` Jason Gunthorpe
2023-01-11 14:24 ` Christian König
2023-01-12 8:59 ` Baolu Lu
[not found] ` <41e25f9f-b106-de77-97ab-d50196de7514@amd.com>
2023-01-11 14:36 ` Jason Gunthorpe
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=Y769WqrbEUPQ3pt7@nvidia.com \
--to=jgg@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=christian.koenig@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=jroedel@suse.de \
--cc=kevin.tian@intel.com \
--cc=linux-pci@vger.kernel.org \
--cc=tony.zhu@intel.com \
/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