From: "Kuehling, Felix" <felix.kuehling@amd.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Gerd Bayer" <gbayer@linux.ibm.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Selvin Xavier" <selvin.xavier@broadcom.com>,
"Kalesh AP" <kalesh-anakkur.purayil@broadcom.com>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Leon Romanovsky" <leon@kernel.org>,
"Michal Kalderon" <mkalderon@marvell.com>,
"Saeed Mahameed" <saeedm@nvidia.com>,
"Tariq Toukan" <tariqt@nvidia.com>,
"Mark Bloch" <mbloch@nvidia.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Jay Cornwall" <Jay.Cornwall@amd.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Niklas Schnelle" <schnelle@linux.ibm.com>,
"Gerald Schaefer" <gerald.schaefer@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Sven Schnelle" <svens@linux.ibm.com>,
"Alexander Schmidt" <alexs@linux.ibm.com>,
linux-s390@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH v7 1/3] PCI: AtomicOps: Do not enable requests by RCiEPs
Date: Tue, 31 Mar 2026 16:12:23 -0400 [thread overview]
Message-ID: <8dd22066-c0a1-4f63-b5b6-4606446a49fb@amd.com> (raw)
In-Reply-To: <20260331190103.GA150932@bhelgaas>
On 2026-03-31 15:01, Bjorn Helgaas wrote:
> On Tue, Mar 31, 2026 at 02:39:26PM -0400, Kuehling, Felix wrote:
>> On 2026-03-31 14:09, Bjorn Helgaas wrote:
>>> On Mon, Mar 30, 2026 at 08:01:57PM -0400, Kuehling, Felix wrote:
>>>> On 2026-03-30 17:42, Bjorn Helgaas wrote:
>>>>> [+to amdgpu, bnxe_re, mlx5 IB, qedr, mlx5 maintainers]
>>>>>
>>>>> On Mon, Mar 30, 2026 at 03:09:44PM +0200, Gerd Bayer wrote:
>>>>>> Since root complex integrated end points (RCiEPs) attach to a bus that
>>>>>> has no bridge device describing the root port, the capability to
>>>>>> complete AtomicOps requests cannot be determined with PCIe methods.
>>>>>>
>>>>>> Change default of pci_enable_atomic_ops_to_root() to not enable
>>>>>> AtomicOps requests on RCiEPs.
>>>>> I know I suggested this because there's nothing explicit that tells us
>>>>> whether the RC supports atomic ops from RCiEPs [1]. But I'm concerned
>>>>> that GPUs, infiniband HCAs, and NICs that use atomic ops may be
>>>>> implemented as RCiEPs and would be broken by this.
>>>> FWIW, on AMD APUs our driver doesn't call pci_enable_atomic_ops_to_root. It
>>>> just assumes that the GPU can do atomic accesses because it doesn't actually
>>>> go through PCIe: https://elixir.bootlin.com/linux/v6.19.10/source/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c#L4785
>>> What does this mean for the other branch that *does* use
>>> pci_enable_atomic_ops_to_root()? Can any of those devices be RCiEPs?
>> Most AMD GPUs are not integrated endpoints. APUs are integrated. There are
>> A+A GPUs where the GPUs are separate from the CPU but part of the same
>> coherent data fabric as the CPU (adev->gmc.xbmi.connected_to_cpu == true).
>> Those may also be considered RCiEPs. (I'm not sure about that, is there an
>> easy way to check with lspci?) We may need to include that in the same
>> branch as APUs.
> Yep, for RCiEPs, "lspci -v" should say something like this:
>
> Capabilities: [64] Express Root Complex Integrated Endpoint
>
> Dmesg logs from recent kernels would also include it like this:
>
> pci 0000:00:02.0: [8086:5916] type 00 class 0x030000 PCIe Root Complex Integrated Endpoint
>
> An RCiEP would be on the root bus; it would not be below a Root Port.
I'm getting this from lspci:
Capabilities: [64] Express Endpoint, MSI 00
Regards,
Felix
>
>> You can see that we did that for a new generation of A+A GPU here: https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c?ref_type=heads#L3920.
>> We'd need to confirm that the same works for MI200 A+A GPUs as well.
>>>>> These drivers use pci_enable_atomic_ops_to_root():
>>>>>
>>>>> amdgpu
>>>>> bnxt_re (infiniband)
>>>>> mlx5 (infinband)
>>>>> qedr (infiniband)
>>>>> mlx5 (ethernet)
>>>>>
>>>>> Maybe we should assume that because RCiEPs are directly integrated
>>>>> into the RC, the RCiEP would only allow AtomicOp Requester Enable to
>>>>> be set if the RC supports atomic ops?
>>>>>
>>>>> I don't like making assumptions like that, but it'd be worse to break
>>>>> these devices.
>>>>>
>>>>> [1] https://lore.kernel.org/all/20260326164002.GA1325368@bhelgaas
>>>>>
>>>>>> Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
>>>>>> ---
>>>>>> drivers/pci/pci.c | 5 ++---
>>>>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>>>> index 8479c2e1f74f1044416281aba11bf071ea89488a..135e5b591df405e87e7f520a618d7e2ccba55ce1 100644
>>>>>> --- a/drivers/pci/pci.c
>>>>>> +++ b/drivers/pci/pci.c
>>>>>> @@ -3692,15 +3692,14 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>>>>>> /*
>>>>>> * Per PCIe r4.0, sec 6.15, endpoints and root ports may be
>>>>>> - * AtomicOp requesters. For now, we only support endpoints as
>>>>>> - * requesters and root ports as completers. No endpoints as
>>>>>> + * AtomicOp requesters. For now, we only support (legacy) endpoints
>>>>>> + * as requesters and root ports as completers. No endpoints as
>>>>>> * completers, and no peer-to-peer.
>>>>>> */
>>>>>> switch (pci_pcie_type(dev)) {
>>>>>> case PCI_EXP_TYPE_ENDPOINT:
>>>>>> case PCI_EXP_TYPE_LEG_END:
>>>>>> - case PCI_EXP_TYPE_RC_END:
>>>>>> break;
>>>>>> default:
>>>>>> return -EINVAL;
>>>>>>
>>>>>> --
>>>>>> 2.51.0
>>>>>>
next prev parent reply other threads:[~2026-03-31 20:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 13:09 [PATCH v7 0/3] PCI: AtomicOps: Fix pci_enable_atomic_ops_to_root() Gerd Bayer
2026-03-30 13:09 ` [PATCH v7 1/3] PCI: AtomicOps: Do not enable requests by RCiEPs Gerd Bayer
2026-03-30 21:42 ` Bjorn Helgaas
2026-03-30 22:26 ` Jason Gunthorpe
2026-03-31 0:01 ` Kuehling, Felix
2026-03-31 18:09 ` Bjorn Helgaas
2026-03-31 18:39 ` Kuehling, Felix
2026-03-31 19:01 ` Bjorn Helgaas
2026-03-31 20:12 ` Kuehling, Felix [this message]
2026-03-30 13:09 ` [PATCH v7 2/3] PCI: AtomicOps: Do not enable without support in root port Gerd Bayer
2026-04-01 17:27 ` Bjorn Helgaas
2026-04-02 14:44 ` Gerd Bayer
2026-03-30 13:09 ` [PATCH v7 3/3] PCI: AtomicOps: Update references to PCIe spec Gerd Bayer
2026-04-02 16:38 ` [PATCH v7 0/3] PCI: AtomicOps: Fix pci_enable_atomic_ops_to_root() Bjorn Helgaas
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=8dd22066-c0a1-4f63-b5b6-4606446a49fb@amd.com \
--to=felix.kuehling@amd.com \
--cc=Jay.Cornwall@amd.com \
--cc=agordeev@linux.ibm.com \
--cc=alexander.deucher@amd.com \
--cc=alexs@linux.ibm.com \
--cc=bhelgaas@google.com \
--cc=borntraeger@linux.ibm.com \
--cc=christian.koenig@amd.com \
--cc=gbayer@linux.ibm.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=helgaas@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jgg@ziepe.ca \
--cc=kalesh-anakkur.purayil@broadcom.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=mkalderon@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@nvidia.com \
--cc=schnelle@linux.ibm.com \
--cc=selvin.xavier@broadcom.com \
--cc=svens@linux.ibm.com \
--cc=tariqt@nvidia.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