[PATCH] PCI: Accept AtomicOps already enabled by the hypervisor

[PATCH] PCI: Accept AtomicOps already enabled by the hypervisor

[Nikola Prica]

From: Nikola Prica <nikola.prica@amd.com>

pci_enable_atomic_ops_to_root() currently fails when no Root Port is
visible. That is common in passthrough guests (ESXi, Hyper-V): the
endpoint is assigned to the VM, but the guest topology has no Root
Port above it.

In those setups the hypervisor may already have enabled AtomicOp
Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
treat AtomicOps as already enabled and return success instead of
failing the Root Port walk.

Signed-off-by: Nikola Prica <nikola.prica@amd.com>
---
 drivers/pci/pci.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b2879a6be5f8..7c62c7f31757 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3768,6 +3768,14 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
 		return -EINVAL;
 	}
 
+	/*
+	 * Some hypervisors already set AtomicOp Requester Enable.  If it
+	 * is already set, there is nothing more to do.
+	 */
+	pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
+	if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
+		return 0;
+
 	root = pcie_find_root_port(dev);
 	if (!root)
 		return -EINVAL;

base-commit: 89a312991dc6e638a36adc43ccb91dbc25504c04
-- 
2.34.1

Re: [PATCH] PCI: Accept AtomicOps already enabled by the hypervisor

[Christian König]

On 9/3/26 14:12, Nikola Prica wrote:
> From: Nikola Prica <nikola.prica@amd.com>
> 
> pci_enable_atomic_ops_to_root() currently fails when no Root Port is
> visible. That is common in passthrough guests (ESXi, Hyper-V): the
> endpoint is assigned to the VM, but the guest topology has no Root
> Port above it.
> 
> In those setups the hypervisor may already have enabled AtomicOp
> Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
> treat AtomicOps as already enabled and return success instead of
> failing the Root Port walk.
> 
> Signed-off-by: Nikola Prica <nikola.prica@amd.com>
> ---
>  drivers/pci/pci.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b2879a6be5f8..7c62c7f31757 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3768,6 +3768,14 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>  		return -EINVAL;
>  	}
>  
> +	/*
> +	 * Some hypervisors already set AtomicOp Requester Enable.  If it
> +	 * is already set, there is nothing more to do.
> +	 */
> +	pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
> +	if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
> +		return 0;
> +

I think for a bit more defensiveness we should only do this when we can't find a root port. E.g. under the if (!root) below.

Apart from that looks totally sane to me.

Regards,
Christian.

>  	root = pcie_find_root_port(dev);
>  	if (!root)
>  		return -EINVAL;
> 
> base-commit: 89a312991dc6e638a36adc43ccb91dbc25504c04

Re: [PATCH] PCI: Accept AtomicOps already enabled by the hypervisor

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unconditionally returning success when ATOMIC_REQ is already set bypasses root port and bridge capability validation.
--

commit 174dddecfad7749ccba344bb23492b342569e86c
Author: Nikola Prica <nikola.prica@amd.com>

PCI: Accept AtomicOps already enabled by the hypervisor

This commit modifies pci_enable_atomic_ops_to_root() to check if the
PCI_EXP_DEVCTL2_ATOMIC_REQ bit is already set by a hypervisor. If it is, the
function returns success early to avoid failing in passthrough topologies
without a visible Root Port.

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b2879a6be5f80..7c62c7f317572 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3768,6 +3768,14 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>  		return -EINVAL;
>  	}
>  
> +	/*
> +	 * Some hypervisors already set AtomicOp Requester Enable.  If it
> +	 * is already set, there is nothing more to do.
> +	 */
> +	pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
> +	if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
> +		return 0;

[Severity: High]
Will this unconditional early return bypass the capability validation for newly
requested atomic sizes?

When drivers or subsystems sequentially check for atomic support, they call
pci_enable_atomic_ops_to_root() for different sizes. For example, in
drivers/vfio/pci/vfio_pci_core.c:vfio_pci_info_atomic_cap() (around line
1059), the code sequentially checks for 32-bit and 64-bit atomic support:

vfio_pci_core.c:vfio_pci_info_atomic_cap() {
    ...
    if ((devcap2 & PCI_EXP_DEVCAP2_ATOMIC_COMP64) &&
        !pci_enable_atomic_ops_to_root(pdev, PCI_EXP_DEVCAP2_ATOMIC_COMP64))
        cap.flags |= VFIO_PCI_ATOMIC_COMP64;
    ...
}

A similar sequential check occurs in
drivers/infiniband/hw/bnxt_re/qplib_res.c:bnxt_qplib_determine_atomics()
(around line 1001).

The first successful call (e.g., for COMP32) validates the topology and sets
the ATOMIC_REQ bit on the endpoint. If a subsequent call is made for a larger
size (like COMP64), this new logic sees the ATOMIC_REQ bit is already set and
instantly returns success.

By returning early, doesn't this bypass the cap_mask checks on the root port
and bridges for the larger atomic size?

Could this cause the kernel to incorrectly advertise 64-bit or 128-bit atomic
support to VMs or drivers when the root port only supports 32-bit? If a driver
or VM attempts to use these unsupported sizes, the root port would treat them
as an Unsupported Request (UR), potentially triggering a fatal AER error and
crashing the system or terminating the VM.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903121218.4955-1-nikprica@amd.com?part=1

Re: [PATCH] PCI: Accept AtomicOps already enabled by the hypervisor

[Prica, Nikola]

Ok. That makes sense. I'll address it in v2 and incorporate Christians comment too.

On 9/3/2026 2:12 PM, sashiko-bot@kernel.org wrote:
> [You don't often get email from sashiko-bot@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Unconditionally returning success when ATOMIC_REQ is already set bypasses root port and bridge capability validation.
> --
> 
> commit 174dddecfad7749ccba344bb23492b342569e86c
> Author: Nikola Prica <nikola.prica@amd.com>
> 
> PCI: Accept AtomicOps already enabled by the hypervisor
> 
> This commit modifies pci_enable_atomic_ops_to_root() to check if the
> PCI_EXP_DEVCTL2_ATOMIC_REQ bit is already set by a hypervisor. If it is, the
> function returns success early to avoid failing in passthrough topologies
> without a visible Root Port.
> 
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index b2879a6be5f80..7c62c7f317572 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3768,6 +3768,14 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>>                return -EINVAL;
>>        }
>>
>> +     /*
>> +      * Some hypervisors already set AtomicOp Requester Enable.  If it
>> +      * is already set, there is nothing more to do.
>> +      */
>> +     pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
>> +     if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
>> +             return 0;
> 
> [Severity: High]
> Will this unconditional early return bypass the capability validation for newly
> requested atomic sizes?
> 
> When drivers or subsystems sequentially check for atomic support, they call
> pci_enable_atomic_ops_to_root() for different sizes. For example, in
> drivers/vfio/pci/vfio_pci_core.c:vfio_pci_info_atomic_cap() (around line
> 1059), the code sequentially checks for 32-bit and 64-bit atomic support:
> 
> vfio_pci_core.c:vfio_pci_info_atomic_cap() {
>      ...
>      if ((devcap2 & PCI_EXP_DEVCAP2_ATOMIC_COMP64) &&
>          !pci_enable_atomic_ops_to_root(pdev, PCI_EXP_DEVCAP2_ATOMIC_COMP64))
>          cap.flags |= VFIO_PCI_ATOMIC_COMP64;
>      ...
> }
> 
> A similar sequential check occurs in
> drivers/infiniband/hw/bnxt_re/qplib_res.c:bnxt_qplib_determine_atomics()
> (around line 1001).
> 
> The first successful call (e.g., for COMP32) validates the topology and sets
> the ATOMIC_REQ bit on the endpoint. If a subsequent call is made for a larger
> size (like COMP64), this new logic sees the ATOMIC_REQ bit is already set and
> instantly returns success.
> 
> By returning early, doesn't this bypass the cap_mask checks on the root port
> and bridges for the larger atomic size?
> 
> Could this cause the kernel to incorrectly advertise 64-bit or 128-bit atomic
> support to VMs or drivers when the root port only supports 32-bit? If a driver
> or VM attempts to use these unsupported sizes, the root port would treat them
> as an Unsupported Request (UR), potentially triggering a fatal AER error and
> crashing the system or terminating the VM.
> 
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260903121218.4955-1-nikprica@amd.com?part=1

[PATCH v2] PCI: Accept AtomicOps already enabled by the hypervisor

[Nikola Prica]

From: Nikola Prica <nikola.prica@amd.com>

pci_enable_atomic_ops_to_root() currently fails when no root port is
visible. That is common in passthrough guests (ESXi, Hyper-V): the
endpoint is assigned to the VM, but the guest topology has no root
port above it.

In those setups the hypervisor may already have enabled AtomicOp
requester enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
treat AtomicOps as already enabled and return success instead of
failing the Root Port walk.

Signed-off-by: Nikola Prica <nikola.prica@amd.com>
---
Changes in v2:
- Be more strict and only apply logic in headless device case.

 drivers/pci/pci.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b2879a6be5f8..62729ade496f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
 	}
 
 	root = pcie_find_root_port(dev);
-	if (!root)
+	if (!root) {
+		/*
+		 * A hypervisor may expose a headless topology with no
+		 * visible root port.  If it has already set AtomicOp
+		 * Requester Enable, there is nothing more to do.
+		 */
+		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
+		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
+			return 0;
+
 		return -EINVAL;
+	}
 
 	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
 	if ((cap & cap_mask) != cap_mask)
-- 
2.34.1

Re: [PATCH v2] PCI: Accept AtomicOps already enabled by the hypervisor

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Bypassing the cap_mask capability check blindly assumes all requested PCIe AtomicOp sizes are supported, risking Unsupported Request (UR) errors.
--

commit 23f7770048aa6bf9d34e0cd8e0687398f5697661
Author: Nikola Prica <nikola.prica@amd.com>

PCI: Accept AtomicOps already enabled by the hypervisor

This patch modifies pci_enable_atomic_ops_to_root() to support passthrough
guests in headless topologies where no root port is visible. If the hypervisor
has already set PCI_EXP_DEVCTL2_ATOMIC_REQ on the device, it treats AtomicOps
as enabled and returns success instead of failing the topology walk.

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b2879a6be5f80..62729ade496fc 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>  	}
>  
>  	root = pcie_find_root_port(dev);
> -	if (!root)
> +	if (!root) {
> +		/*
> +		 * A hypervisor may expose a headless topology with no
> +		 * visible root port.  If it has already set AtomicOp
> +		 * Requester Enable, there is nothing more to do.
> +		 */
> +		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
> +		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
> +			return 0;

[Severity: High]
Does unconditionally returning success here bypass the capability mask
validation?

Guest drivers (e.g., bnxt_re, amdgpu, or vfio) call
pci_enable_atomic_ops_to_root() passing a specific cap_mask to probe whether
certain atomic sizes (e.g., 64-bit or 128-bit) are supported by the routing
topology. By returning early, we skip the cap_mask validation against the
root port's DEVCAP2 register that typically happens right after this check.

If the physical root port only supports 32-bit atomics but the driver
believes 64-bit sizes are supported due to this return, could this result in
PCIe Unsupported Request (UR) errors and potentially trigger fatal Advanced
Error Reporting (AER) events that crash the device or VM?

> +
>  		return -EINVAL;
> +	}
>  
>  	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>  	if ((cap & cap_mask) != cap_mask)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907161701.454364-1-nikprica@amd.com?part=1

Re: [PATCH v2] PCI: Accept AtomicOps already enabled by the hypervisor

[Prica, Nikola]

On 9/7/2026 6:15 PM, sashiko-bot@kernel.org wrote:
> [You don't often get email from sashiko-bot@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Bypassing the cap_mask capability check blindly assumes all requested PCIe AtomicOp sizes are supported, risking Unsupported Request (UR) errors.
> --

In a headless topology with no root port, the hypervisor owns the device
topology and is responsible for presenting it to the guest. The capability
mask check is not bypassed blindly — we rely on the hypervisor to have
verified AtomicOp support before enabling the Requester capability. This
is consistent with the existing trust model for passthrough configurations,
where the hypervisor already controls which PCIe capabilities are exposed
to the guest.

If the hypervisor enables the AtomicOp Requester bit without verifying
target support, that is a hypervisor bug, not something the guest driver
can or should guard against.


> commit 23f7770048aa6bf9d34e0cd8e0687398f5697661
> Author: Nikola Prica <nikola.prica@amd.com>
> 
> PCI: Accept AtomicOps already enabled by the hypervisor
> 
> This patch modifies pci_enable_atomic_ops_to_root() to support passthrough
> guests in headless topologies where no root port is visible. If the hypervisor
> has already set PCI_EXP_DEVCTL2_ATOMIC_REQ on the device, it treats AtomicOps
> as enabled and returns success instead of failing the topology walk.
> 
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index b2879a6be5f80..62729ade496fc 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>>        }
>>
>>        root = pcie_find_root_port(dev);
>> -     if (!root)
>> +     if (!root) {
>> +             /*
>> +              * A hypervisor may expose a headless topology with no
>> +              * visible root port.  If it has already set AtomicOp
>> +              * Requester Enable, there is nothing more to do.
>> +              */
>> +             pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
>> +             if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
>> +                     return 0;
> 
> [Severity: High]
> Does unconditionally returning success here bypass the capability mask
> validation?
> 
> Guest drivers (e.g., bnxt_re, amdgpu, or vfio) call
> pci_enable_atomic_ops_to_root() passing a specific cap_mask to probe whether
> certain atomic sizes (e.g., 64-bit or 128-bit) are supported by the routing
> topology. By returning early, we skip the cap_mask validation against the
> root port's DEVCAP2 register that typically happens right after this check.
> 
> If the physical root port only supports 32-bit atomics but the driver
> believes 64-bit sizes are supported due to this return, could this result in
> PCIe Unsupported Request (UR) errors and potentially trigger fatal Advanced
> Error Reporting (AER) events that crash the device or VM?
> 
>> +
>>                return -EINVAL;
>> +     }
>>
>>        pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>>        if ((cap & cap_mask) != cap_mask)
> 
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260907161701.454364-1-nikprica@amd.com?part=1

Re: [PATCH v2] PCI: Accept AtomicOps already enabled by the hypervisor

[Christian König]

On 9/7/26 18:17, Nikola Prica wrote:
> From: Nikola Prica <nikola.prica@amd.com>
> 
> pci_enable_atomic_ops_to_root() currently fails when no root port is
> visible. That is common in passthrough guests (ESXi, Hyper-V): the
> endpoint is assigned to the VM, but the guest topology has no root
> port above it.
> 
> In those setups the hypervisor may already have enabled AtomicOp
> requester enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
> treat AtomicOps as already enabled and return success instead of
> failing the Root Port walk.
> 
> Signed-off-by: Nikola Prica <nikola.prica@amd.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

Bjorn first of all any objections to this? It sounds save to me, only a handful of drivers actually use this function and it generally seems to be the right things to do.

Then if you agree any objections to up-streaming it through AMDs GPU branch? That would make things a bit easier for us.

Thanks,
Christian.

> ---
> Changes in v2:
> - Be more strict and only apply logic in headless device case.
> 
>  drivers/pci/pci.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b2879a6be5f8..62729ade496f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>  	}
>  
>  	root = pcie_find_root_port(dev);
> -	if (!root)
> +	if (!root) {
> +		/*
> +		 * A hypervisor may expose a headless topology with no
> +		 * visible root port.  If it has already set AtomicOp
> +		 * Requester Enable, there is nothing more to do.
> +		 */
> +		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
> +		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
> +			return 0;
> +
>  		return -EINVAL;
> +	}
>  
>  	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>  	if ((cap & cap_mask) != cap_mask)

Re: [PATCH v2] PCI: Accept AtomicOps already enabled by the hypervisor

[Prica, Nikola]

Hi Bjorn, any thoughs on this? Do you need more information?

Thanks,
Nikola

On 9/8/2026 10:47 AM, Christian König wrote:
> On 9/7/26 18:17, Nikola Prica wrote:
>> From: Nikola Prica <nikola.prica@amd.com>
>>
>> pci_enable_atomic_ops_to_root() currently fails when no root port is
>> visible. That is common in passthrough guests (ESXi, Hyper-V): the
>> endpoint is assigned to the VM, but the guest topology has no root
>> port above it.
>>
>> In those setups the hypervisor may already have enabled AtomicOp
>> requester enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
>> treat AtomicOps as already enabled and return success instead of
>> failing the Root Port walk.
>>
>> Signed-off-by: Nikola Prica <nikola.prica@amd.com>
> 
> Reviewed-by: Christian König <christian.koenig@amd.com>
> 
> Bjorn first of all any objections to this? It sounds save to me, only a handful of drivers actually use this function and it generally seems to be the right things to do.
> 
> Then if you agree any objections to up-streaming it through AMDs GPU branch? That would make things a bit easier for us.
> 
> Thanks,
> Christian.
> 
>> ---
>> Changes in v2:
>> - Be more strict and only apply logic in headless device case.
>>
>>   drivers/pci/pci.c | 12 +++++++++++-
>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index b2879a6be5f8..62729ade496f 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>>   	}
>>   
>>   	root = pcie_find_root_port(dev);
>> -	if (!root)
>> +	if (!root) {
>> +		/*
>> +		 * A hypervisor may expose a headless topology with no
>> +		 * visible root port.  If it has already set AtomicOp
>> +		 * Requester Enable, there is nothing more to do.
>> +		 */
>> +		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
>> +		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
>> +			return 0;
>> +
>>   		return -EINVAL;
>> +	}
>>   
>>   	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>>   	if ((cap & cap_mask) != cap_mask)
> 

Re: [PATCH v2] PCI: Accept AtomicOps already enabled by the hypervisor

[Gerd Bayer]

On Mon, 2026-09-07 at 18:17 +0200, Nikola Prica wrote:
> From: Nikola Prica <nikola.prica@amd.com>
> 
> pci_enable_atomic_ops_to_root() currently fails when no root port is
> visible. That is common in passthrough guests (ESXi, Hyper-V): the
> endpoint is assigned to the VM, but the guest topology has no root
> port above it.
> 
> In those setups the hypervisor may already have enabled AtomicOp
> requester enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
> treat AtomicOps as already enabled and return success instead of
> failing the Root Port walk.

Hi Nikola,

your patch got me interested, since it touches those parts of
pci_enable_atomic_ops_to_root() that commit 1ae8c4ce1570 ("PCI: Enable
AtomicOps only if Root Port supports them") has modified.

I like your solution for putting the hypervisor in control of the
enablement of Atomic Ops on root-less PCI functions and did test your
change on s390/Connect-X, successfully.

> Signed-off-by: Nikola Prica <nikola.prica@amd.com>

If that commit of mine regressed your use-cases, you might even want to
add a Fixes: tag?

> ---
> Changes in v2:
> - Be more strict and only apply logic in headless device case.
> 
>  drivers/pci/pci.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b2879a6be5f8..62729ade496f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>  	}
>  
>  	root = pcie_find_root_port(dev);
> -	if (!root)
> +	if (!root) {
> +		/*
> +		 * A hypervisor may expose a headless topology with no
> +		 * visible root port.  If it has already set AtomicOp
> +		 * Requester Enable, there is nothing more to do.
> +		 */
> +		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
> +		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
> +			return 0;
> +
>  		return -EINVAL;
> +	}
>  
>  	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>  	if ((cap & cap_mask) != cap_mask)

At any rate, feel free to add my

Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Tested-by: Gerd Bayer <gbayer@linux.ibm.com>

Re: [PATCH v2] PCI: Accept AtomicOps already enabled by the hypervisor

[Christian König]

On 9/14/26 15:41, Gerd Bayer wrote:
> 
> On Mon, 2026-09-07 at 18:17 +0200, Nikola Prica wrote:
>> From: Nikola Prica <nikola.prica@amd.com>
>>
>> pci_enable_atomic_ops_to_root() currently fails when no root port is
>> visible. That is common in passthrough guests (ESXi, Hyper-V): the
>> endpoint is assigned to the VM, but the guest topology has no root
>> port above it.
>>
>> In those setups the hypervisor may already have enabled AtomicOp
>> requester enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
>> treat AtomicOps as already enabled and return success instead of
>> failing the Root Port walk.
> 
> Hi Nikola,
> 
> your patch got me interested, since it touches those parts of
> pci_enable_atomic_ops_to_root() that commit 1ae8c4ce1570 ("PCI: Enable
> AtomicOps only if Root Port supports them") has modified.
> 
> I like your solution for putting the hypervisor in control of the
> enablement of Atomic Ops on root-less PCI functions and did test your
> change on s390/Connect-X, successfully.
> 
>> Signed-off-by: Nikola Prica <nikola.prica@amd.com>
> 
> If that commit of mine regressed your use-cases, you might even want to
> add a Fixes: tag?

Oh, that's an interesting point. I wasn't aware that the root complex check was added so recently.

So indeed question @Nikola did that worked out of the box before kernel 7.1? If yes then that would be a regression.

Regards,
Christian.

> 
>> ---
>> Changes in v2:
>> - Be more strict and only apply logic in headless device case.
>>
>>  drivers/pci/pci.c | 12 +++++++++++-
>>  1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index b2879a6be5f8..62729ade496f 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>>       }
>>
>>       root = pcie_find_root_port(dev);
>> -     if (!root)
>> +     if (!root) {
>> +             /*
>> +              * A hypervisor may expose a headless topology with no
>> +              * visible root port.  If it has already set AtomicOp
>> +              * Requester Enable, there is nothing more to do.
>> +              */
>> +             pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
>> +             if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
>> +                     return 0;
>> +
>>               return -EINVAL;
>> +     }
>>
>>       pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>>       if ((cap & cap_mask) != cap_mask)
> 
> At any rate, feel free to add my
> 
> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
> Tested-by: Gerd Bayer <gbayer@linux.ibm.com>

Re: [PATCH v2] PCI: Accept AtomicOps already enabled by the hypervisor

[Prica, Nikola]

Hi Christian, Gerd,

Yes, this fixes a recent regression that we recognized with 6.8.0-135-generic kernel release. And it is the commit that Gerd referenced. I'll add Fixes tag.

Thanks for your attention and help!

Regards,
Nikola

On 9/14/2026 3:54 PM, Christian König wrote:
> On 9/14/26 15:41, Gerd Bayer wrote:
>>
>> On Mon, 2026-09-07 at 18:17 +0200, Nikola Prica wrote:
>>> From: Nikola Prica <nikola.prica@amd.com>
>>>
>>> pci_enable_atomic_ops_to_root() currently fails when no root port is
>>> visible. That is common in passthrough guests (ESXi, Hyper-V): the
>>> endpoint is assigned to the VM, but the guest topology has no root
>>> port above it.
>>>
>>> In those setups the hypervisor may already have enabled AtomicOp
>>> requester enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
>>> treat AtomicOps as already enabled and return success instead of
>>> failing the Root Port walk.
>>
>> Hi Nikola,
>>
>> your patch got me interested, since it touches those parts of
>> pci_enable_atomic_ops_to_root() that commit 1ae8c4ce1570 ("PCI: Enable
>> AtomicOps only if Root Port supports them") has modified.
>>
>> I like your solution for putting the hypervisor in control of the
>> enablement of Atomic Ops on root-less PCI functions and did test your
>> change on s390/Connect-X, successfully.
>>
>>> Signed-off-by: Nikola Prica <nikola.prica@amd.com>
>>
>> If that commit of mine regressed your use-cases, you might even want to
>> add a Fixes: tag?
> 
> Oh, that's an interesting point. I wasn't aware that the root complex check was added so recently.
> 
> So indeed question @Nikola did that worked out of the box before kernel 7.1? If yes then that would be a regression.
> 
> Regards,
> Christian.
> 
>>
>>> ---
>>> Changes in v2:
>>> - Be more strict and only apply logic in headless device case.
>>>
>>>   drivers/pci/pci.c | 12 +++++++++++-
>>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index b2879a6be5f8..62729ade496f 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>>>        }
>>>
>>>        root = pcie_find_root_port(dev);
>>> -     if (!root)
>>> +     if (!root) {
>>> +             /*
>>> +              * A hypervisor may expose a headless topology with no
>>> +              * visible root port.  If it has already set AtomicOp
>>> +              * Requester Enable, there is nothing more to do.
>>> +              */
>>> +             pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
>>> +             if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
>>> +                     return 0;
>>> +
>>>                return -EINVAL;
>>> +     }
>>>
>>>        pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>>>        if ((cap & cap_mask) != cap_mask)
>>
>> At any rate, feel free to add my
>>
>> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
>> Tested-by: Gerd Bayer <gbayer@linux.ibm.com>
> 

[PATCH v3] PCI: Accept AtomicOps already enabled by the hypervisor

[Nikola Prica]

From: Nikola Prica <nikola.prica@amd.com>

pci_enable_atomic_ops_to_root() currently fails when no Root Port is
visible. That is common in passthrough guests (ESXi, Hyper-V): the
endpoint is assigned to the VM, but the guest topology has no Root
Port above it.

In those setups the hypervisor may already have enabled AtomicOp
Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
treat AtomicOps as already enabled and return success instead of
failing the Root Port walk.

Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them")
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Tested-by: Gerd Bayer <gbayer@linux.ibm.com>
Signed-off-by: Nikola Prica <nikola.prica@amd.com>

---
v3: Add Fixes tag
v2: Be more strict and only apply logic in headless device case.
---
 drivers/pci/pci.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b2879a6be5f8..62729ade496f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
 	}
 
 	root = pcie_find_root_port(dev);
-	if (!root)
+	if (!root) {
+		/*
+		 * A hypervisor may expose a headless topology with no
+		 * visible root port.  If it has already set AtomicOp
+		 * Requester Enable, there is nothing more to do.
+		 */
+		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
+		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
+			return 0;
+
 		return -EINVAL;
+	}
 
 	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
 	if ((cap & cap_mask) != cap_mask)
-- 
2.34.1

Re: [PATCH v3] PCI: Accept AtomicOps already enabled by the hypervisor

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: atomic capabilities check bypass in headless topologies
--

commit 7a2c6321c34255d72f250ecd35fa5e1846785e21
Author: Nikola Prica <nikola.prica@amd.com>

PCI: Accept AtomicOps already enabled by the hypervisor

In passthrough guests without a visible Root Port, this commit allows
pci_enable_atomic_ops_to_root() to return success if AtomicOps are already
enabled by the hypervisor.

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b2879a6be5f80..62729ade496fc 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>  	}
>  
>  	root = pcie_find_root_port(dev);
> -	if (!root)
> +	if (!root) {
> +		/*
> +		 * A hypervisor may expose a headless topology with no
> +		 * visible root port.  If it has already set AtomicOp
> +		 * Requester Enable, there is nothing more to do.
> +		 */
> +		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
> +		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
> +			return 0;

[Severity: High]
Does this bypass the cap_mask size verification in headless topologies?

pci_enable_atomic_ops_to_root() requires a cap_mask parameter (e.g.,
PCI_EXP_DEVCAP2_ATOMIC_COMP64) to verify that the physical Completer supports
the specific atomic sizes required by the driver.

In the newly added headless topology path (!root), the function checks if the
PCI_EXP_DEVCTL2_ATOMIC_REQ bit is already set on the endpoint. If the bit is
set, it returns 0 (success), completely discarding the caller's cap_mask size
requirements.

The ATOMIC_REQ flag is merely a boolean enable bit for initiating atomics; it
does not guarantee that the physical Completer supports the specific sizes
requested in cap_mask.

If a hypervisor or host enables Atomics for 32-bit sizes, setting ATOMIC_REQ,
but the guest driver requires 64-bit or 128-bit Atomics, this function will
falsely return success. The guest driver will then issue unsupported 64/128-bit
Atomics, which the physical hardware will reject with an Unsupported Request
(UR) fault, potentially triggering an AER and crashing the system.

> +
>  		return -EINVAL;
> +	}
>  
>  	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>  	if ((cap & cap_mask) != cap_mask)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918092857.648810-1-nikprica@amd.com?part=1

Re: [PATCH v3] PCI: Accept AtomicOps already enabled by the hypervisor

[Christian König]

On 9/18/26 11:28, Nikola Prica wrote:
> From: Nikola Prica <nikola.prica@amd.com>
> 
> pci_enable_atomic_ops_to_root() currently fails when no Root Port is
> visible. That is common in passthrough guests (ESXi, Hyper-V): the
> endpoint is assigned to the VM, but the guest topology has no Root
> Port above it.
> 
> In those setups the hypervisor may already have enabled AtomicOp
> Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
> treat AtomicOps as already enabled and return success instead of
> failing the Root Port walk.
> 
> Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them")
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
> Tested-by: Gerd Bayer <gbayer@linux.ibm.com>
> Signed-off-by: Nikola Prica <nikola.prica@amd.com>

CC: stable@vger.kernel.org # 7.1+

Bjorn do you want to pick that up? Alternative I can push it through drm-misc-fixes.

Initially I thought that this is a new feature, but it turned out to be an regression and we need to get it fixed ASAP.

Thanks,
Christian.

> ---
> v3: Add Fixes tag
> v2: Be more strict and only apply logic in headless device case.
> ---
>  drivers/pci/pci.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b2879a6be5f8..62729ade496f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>  	}
>  
>  	root = pcie_find_root_port(dev);
> -	if (!root)
> +	if (!root) {
> +		/*
> +		 * A hypervisor may expose a headless topology with no
> +		 * visible root port.  If it has already set AtomicOp
> +		 * Requester Enable, there is nothing more to do.
> +		 */
> +		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
> +		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
> +			return 0;
> +
>  		return -EINVAL;
> +	}
>  
>  	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>  	if ((cap & cap_mask) != cap_mask)

Re: [PATCH v3] PCI: Accept AtomicOps already enabled by the hypervisor

[Bjorn Helgaas]

On Fri, Sep 18, 2026 at 02:07:46PM +0200, Christian König wrote:
> On 9/18/26 11:28, Nikola Prica wrote:
> > From: Nikola Prica <nikola.prica@amd.com>
> > 
> > pci_enable_atomic_ops_to_root() currently fails when no Root Port is
> > visible. That is common in passthrough guests (ESXi, Hyper-V): the
> > endpoint is assigned to the VM, but the guest topology has no Root
> > Port above it.
> > 
> > In those setups the hypervisor may already have enabled AtomicOp
> > Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
> > treat AtomicOps as already enabled and return success instead of
> > failing the Root Port walk.
> > 
> > Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them")
> > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
> > Tested-by: Gerd Bayer <gbayer@linux.ibm.com>
> > Signed-off-by: Nikola Prica <nikola.prica@amd.com>
> 
> CC: stable@vger.kernel.org # 7.1+
> 
> Bjorn do you want to pick that up? Alternative I can push it through
> drm-misc-fixes.
> 
> Initially I thought that this is a new feature, but it turned out to
> be an regression and we need to get it fixed ASAP.

Let me just talk through this to make sure I understand it:

Prior to 1ae8c4ce1570, pci_enable_atomic_ops_to_root() enabled
PCI_EXP_DEVCTL2_ATOMIC_REQ unless a switch port didn't support
AtomicOp routing, a switch upstream port blocked AtomicOp egress, or a
Root Port didn't support the requested sizes.

1ae8c4ce1570 added the requirement that the Root Port be visible,
which fixed an s390 case where pci_enable_atomic_ops_to_root() enabled
AtomicOps when the Root Port did not support them but was not visible
to the kernel.

IIUC the regression is on systems where the Root Port is not visible
but *does* support AtomicOps.  Prior to 1ae8c4ce1570, we would have
enabled AtomicOps in the endpoint and returned success.  After
1ae8c4ce1570, we return -EINVAL because we can't see the Root Port to
verify its support, so the driver thinks it can't use AtomicOps.

This patch fixes the regression by assuming that if we can't see the
Root Port but the endpoint already has AtomicOps enabled, the
hypervisor or host kernel that *can* see the Root Port has already
verified its AtomicOps support, so all we have to do is return success
so the driver can use them.

I'm happy to merge this for v7.3, and I think we should add something
like this to the commit log to make it clear that it's a regression
worthy of a post-merge window fix:

  After 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port
  supports them"), pci_enable_atomic_ops_to_root() always fails if the
  Root Port is not visible.  On systems where the Root Port is not
  visible but *does* support AtomicOps, this is a regression: prior to
  1ae8c4ce1570, it enabled AtomicOps in the endpoint and returned
  success.

Is there any problem report for the regression?  I don't see anything
at https://linux-regtracking.leemhuis.info/regzbot/mainline/, so my
guess is no.

> > ---
> > v3: Add Fixes tag
> > v2: Be more strict and only apply logic in headless device case.
> > ---
> >  drivers/pci/pci.c | 12 +++++++++++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index b2879a6be5f8..62729ade496f 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
> >  	}
> >  
> >  	root = pcie_find_root_port(dev);
> > -	if (!root)
> > +	if (!root) {
> > +		/*
> > +		 * A hypervisor may expose a headless topology with no
> > +		 * visible root port.  If it has already set AtomicOp
> > +		 * Requester Enable, there is nothing more to do.
> > +		 */
> > +		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
> > +		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
> > +			return 0;
> > +
> >  		return -EINVAL;
> > +	}
> >  
> >  	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
> >  	if ((cap & cap_mask) != cap_mask)
> 

Re: [PATCH v3] PCI: Accept AtomicOps already enabled by the hypervisor

[Prica, Nikola]

On 9/18/2026 7:07 PM, Bjorn Helgaas wrote:
> On Fri, Sep 18, 2026 at 02:07:46PM +0200, Christian König wrote:
>> On 9/18/26 11:28, Nikola Prica wrote:
>>> From: Nikola Prica <nikola.prica@amd.com>
>>>
>>> pci_enable_atomic_ops_to_root() currently fails when no Root Port is
>>> visible. That is common in passthrough guests (ESXi, Hyper-V): the
>>> endpoint is assigned to the VM, but the guest topology has no Root
>>> Port above it.
>>>
>>> In those setups the hypervisor may already have enabled AtomicOp
>>> Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
>>> treat AtomicOps as already enabled and return success instead of
>>> failing the Root Port walk.
>>>
>>> Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them")
>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
>>> Tested-by: Gerd Bayer <gbayer@linux.ibm.com>
>>> Signed-off-by: Nikola Prica <nikola.prica@amd.com>
>>
>> CC: stable@vger.kernel.org # 7.1+
>>
>> Bjorn do you want to pick that up? Alternative I can push it through
>> drm-misc-fixes.
>>
>> Initially I thought that this is a new feature, but it turned out to
>> be an regression and we need to get it fixed ASAP.
> 
> Let me just talk through this to make sure I understand it:
> 
> Prior to 1ae8c4ce1570, pci_enable_atomic_ops_to_root() enabled
> PCI_EXP_DEVCTL2_ATOMIC_REQ unless a switch port didn't support
> AtomicOp routing, a switch upstream port blocked AtomicOp egress, or a
> Root Port didn't support the requested sizes.
> 

To be technically correct, some hypervisors do not allow guest VM to
set the PCI_EXP_DEVCTL2_ATOMIC_REQ. So there were cases where this
set command didn't get through. But drivers relied on return value
of pci_enable_atomic_ops_to_root(). It may be good to read it back
to make sure that set went through.

> 1ae8c4ce1570 added the requirement that the Root Port be visible,
> which fixed an s390 case where pci_enable_atomic_ops_to_root() enabled
> AtomicOps when the Root Port did not support them but was not visible
> to the kernel.
> 
> IIUC the regression is on systems where the Root Port is not visible
> but *does* support AtomicOps.  Prior to 1ae8c4ce1570, we would have
> enabled AtomicOps in the endpoint and returned success.  After
> 1ae8c4ce1570, we return -EINVAL because we can't see the Root Port to
> verify its support, so the driver thinks it can't use AtomicOps.
> 
> This patch fixes the regression by assuming that if we can't see the
> Root Port but the endpoint already has AtomicOps enabled, the
> hypervisor or host kernel that *can* see the Root Port has already
> verified its AtomicOps support, so all we have to do is return success
> so the driver can use them.
> 
> I'm happy to merge this for v7.3, and I think we should add something
> like this to the commit log to make it clear that it's a regression
> worthy of a post-merge window fix:
> 
>    After 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port
>    supports them"), pci_enable_atomic_ops_to_root() always fails if the
>    Root Port is not visible.  On systems where the Root Port is not
>    visible but *does* support AtomicOps, this is a regression: prior to
>    1ae8c4ce1570, it enabled AtomicOps in the endpoint and returned
>    success.
> 
> Is there any problem report for the regression?  I don't see anything
> at https://linux-regtracking.leemhuis.info/regzbot/mainline/, so my
> guess is no.
> 

Yes. That is correct. I'll send new v4 patch with updated commit log
that appends your suggestion.


This patch fixes a regression introduced in v7.0-rc1-2-g1ae8c4ce1570.

#regzbot introduced: 1ae8c4ce1570
#regzbot title: Breaks atomics operations for headless passthrough devices


Hope that this will be enough to mark it as regression. If not please let
me know.

One more question though, we encountered this issue with 6.8.0-138-generic
kernel, we figured out the regression point is 6.8.0-135-generic. Since our
validation teams are using older kernels too, is it safe to assume that
fix will be backported in new release for 6.8.0-*-generic version?

Regards,
Nikola


>>> ---
>>> v3: Add Fixes tag
>>> v2: Be more strict and only apply logic in headless device case.
>>> ---
>>>   drivers/pci/pci.c | 12 +++++++++++-
>>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index b2879a6be5f8..62729ade496f 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>>>   	}
>>>   
>>>   	root = pcie_find_root_port(dev);
>>> -	if (!root)
>>> +	if (!root) {
>>> +		/*
>>> +		 * A hypervisor may expose a headless topology with no
>>> +		 * visible root port.  If it has already set AtomicOp
>>> +		 * Requester Enable, there is nothing more to do.
>>> +		 */
>>> +		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
>>> +		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
>>> +			return 0;
>>> +
>>>   		return -EINVAL;
>>> +	}
>>>   
>>>   	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>>>   	if ((cap & cap_mask) != cap_mask)
>>

Re: [PATCH v3] PCI: Accept AtomicOps already enabled by the hypervisor

[Prica, Nikola]

This patch fixes a regression introduced in v7.0-rc1-2-g1ae8c4ce1570.

#regzbot introduced: 1ae8c4ce1570
#regzbot title: Breaks atomics operations for headless passthrough devices

On 9/21/2026 1:04 PM, Prica, Nikola wrote:
> On 9/18/2026 7:07 PM, Bjorn Helgaas wrote:
>> On Fri, Sep 18, 2026 at 02:07:46PM +0200, Christian König wrote:
>>> On 9/18/26 11:28, Nikola Prica wrote:
>>>> From: Nikola Prica <nikola.prica@amd.com>
>>>>
>>>> pci_enable_atomic_ops_to_root() currently fails when no Root Port is
>>>> visible. That is common in passthrough guests (ESXi, Hyper-V): the
>>>> endpoint is assigned to the VM, but the guest topology has no Root
>>>> Port above it.
>>>>
>>>> In those setups the hypervisor may already have enabled AtomicOp
>>>> Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
>>>> treat AtomicOps as already enabled and return success instead of
>>>> failing the Root Port walk.
>>>>
>>>> Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them")
>>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>>> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
>>>> Tested-by: Gerd Bayer <gbayer@linux.ibm.com>
>>>> Signed-off-by: Nikola Prica <nikola.prica@amd.com>
>>>
>>> CC: stable@vger.kernel.org # 7.1+
>>>
>>> Bjorn do you want to pick that up? Alternative I can push it through
>>> drm-misc-fixes.
>>>
>>> Initially I thought that this is a new feature, but it turned out to
>>> be an regression and we need to get it fixed ASAP.
>>
>> Let me just talk through this to make sure I understand it:
>>
>> Prior to 1ae8c4ce1570, pci_enable_atomic_ops_to_root() enabled
>> PCI_EXP_DEVCTL2_ATOMIC_REQ unless a switch port didn't support
>> AtomicOp routing, a switch upstream port blocked AtomicOp egress, or a
>> Root Port didn't support the requested sizes.
>>
> 
> To be technically correct, some hypervisors do not allow guest VM to
> set the PCI_EXP_DEVCTL2_ATOMIC_REQ. So there were cases where this
> set command didn't get through. But drivers relied on return value
> of pci_enable_atomic_ops_to_root(). It may be good to read it back
> to make sure that set went through.
> 
>> 1ae8c4ce1570 added the requirement that the Root Port be visible,
>> which fixed an s390 case where pci_enable_atomic_ops_to_root() enabled
>> AtomicOps when the Root Port did not support them but was not visible
>> to the kernel.
>>
>> IIUC the regression is on systems where the Root Port is not visible
>> but *does* support AtomicOps.  Prior to 1ae8c4ce1570, we would have
>> enabled AtomicOps in the endpoint and returned success.  After
>> 1ae8c4ce1570, we return -EINVAL because we can't see the Root Port to
>> verify its support, so the driver thinks it can't use AtomicOps.
>>
>> This patch fixes the regression by assuming that if we can't see the
>> Root Port but the endpoint already has AtomicOps enabled, the
>> hypervisor or host kernel that *can* see the Root Port has already
>> verified its AtomicOps support, so all we have to do is return success
>> so the driver can use them.
>>
>> I'm happy to merge this for v7.3, and I think we should add something
>> like this to the commit log to make it clear that it's a regression
>> worthy of a post-merge window fix:
>>
>>    After 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port
>>    supports them"), pci_enable_atomic_ops_to_root() always fails if the
>>    Root Port is not visible.  On systems where the Root Port is not
>>    visible but *does* support AtomicOps, this is a regression: prior to
>>    1ae8c4ce1570, it enabled AtomicOps in the endpoint and returned
>>    success.
>>
>> Is there any problem report for the regression?  I don't see anything
>> at https://linux-regtracking.leemhuis.info/regzbot/mainline/, so my
>> guess is no.
>>
> 
> Yes. That is correct. I'll send new v4 patch with updated commit log
> that appends your suggestion.
> 
> 
> This patch fixes a regression introduced in v7.0-rc1-2-g1ae8c4ce1570.
> 
> #regzbot introduced: 1ae8c4ce1570
> #regzbot title: Breaks atomics operations for headless passthrough devices
> 
> 
> Hope that this will be enough to mark it as regression. If not please let
> me know.
> 
> One more question though, we encountered this issue with 6.8.0-138-generic
> kernel, we figured out the regression point is 6.8.0-135-generic. Since our
> validation teams are using older kernels too, is it safe to assume that
> fix will be backported in new release for 6.8.0-*-generic version?
> 
> Regards,
> Nikola
> 
> 
>>>> ---
>>>> v3: Add Fixes tag
>>>> v2: Be more strict and only apply logic in headless device case.
>>>> ---
>>>>   drivers/pci/pci.c | 12 +++++++++++-
>>>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>> index b2879a6be5f8..62729ade496f 100644
>>>> --- a/drivers/pci/pci.c
>>>> +++ b/drivers/pci/pci.c
>>>> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>>>>       }
>>>>       root = pcie_find_root_port(dev);
>>>> -    if (!root)
>>>> +    if (!root) {
>>>> +        /*
>>>> +         * A hypervisor may expose a headless topology with no
>>>> +         * visible root port.  If it has already set AtomicOp
>>>> +         * Requester Enable, there is nothing more to do.
>>>> +         */
>>>> +        pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
>>>> +        if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
>>>> +            return 0;
>>>> +
>>>>           return -EINVAL;
>>>> +    }
>>>>       pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>>>>       if ((cap & cap_mask) != cap_mask)
>>>
> 

[PATCH v4] PCI: Accept AtomicOps already enabled by the hypervisor

[Nikola Prica]

From: Nikola Prica <nikola.prica@amd.com>

pci_enable_atomic_ops_to_root() currently fails when no Root Port is
visible. That is common in passthrough guests (ESXi, Hyper-V): the
endpoint is assigned to the VM, but the guest topology has no Root
Port above it.

In those setups the hypervisor may already have enabled AtomicOp
Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
treat AtomicOps as already enabled and return success instead of
failing the Root Port walk.

After 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port
supports them"), pci_enable_atomic_ops_to_root() always fails if the
Root Port is not visible.  On systems where the Root Port is not
visible but *does* support AtomicOps, this is a regression: prior to
1ae8c4ce1570, it enabled AtomicOps in the endpoint and returned
success.

Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them")
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Tested-by: Gerd Bayer <gbayer@linux.ibm.com>
Signed-off-by: Nikola Prica <nikola.prica@amd.com>

---
v4: Updates commit log to make regression point clear
v3: Add Fixes tag
v2: Be more strict and only apply logic in headless device case.
---
 drivers/pci/pci.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b2879a6be5f8..62729ade496f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
 	}
 
 	root = pcie_find_root_port(dev);
-	if (!root)
+	if (!root) {
+		/*
+		 * A hypervisor may expose a headless topology with no
+		 * visible root port.  If it has already set AtomicOp
+		 * Requester Enable, there is nothing more to do.
+		 */
+		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
+		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
+			return 0;
+
 		return -EINVAL;
+	}
 
 	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
 	if ((cap & cap_mask) != cap_mask)
-- 
2.34.1

Re: [PATCH v4] PCI: Accept AtomicOps already enabled by the hypervisor

[sashiko-bot]

> From: Nikola Prica <nikola.prica@amd.com>
> 
> pci_enable_atomic_ops_to_root() currently fails when no Root Port is
> visible. That is common in passthrough guests (ESXi, Hyper-V): the
> endpoint is assigned to the VM, but the guest topology has no Root
> Port above it.
> 
> In those setups the hypervisor may already have enabled AtomicOp
> Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
> treat AtomicOps as already enabled and return success instead of
> failing the Root Port walk.
> 
> After 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port
> supports them"), pci_enable_atomic_ops_to_root() always fails if the
> Root Port is not visible.  On systems where the Root Port is not
> visible but *does* support AtomicOps, this is a regression: prior to
> 1ae8c4ce1570, it enabled AtomicOps in the endpoint and returned
> success.
> 
> Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them")
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
> Tested-by: Gerd Bayer <gbayer@linux.ibm.com>
> Signed-off-by: Nikola Prica <nikola.prica@amd.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921111903.978687-1-nikprica@amd.com?part=1

Re: [PATCH v4] PCI: Accept AtomicOps already enabled by the hypervisor

[Bjorn Helgaas]

On Mon, Sep 21, 2026 at 01:19:03PM +0200, Nikola Prica wrote:
> From: Nikola Prica <nikola.prica@amd.com>
> 
> pci_enable_atomic_ops_to_root() currently fails when no Root Port is
> visible. That is common in passthrough guests (ESXi, Hyper-V): the
> endpoint is assigned to the VM, but the guest topology has no Root
> Port above it.
> 
> In those setups the hypervisor may already have enabled AtomicOp
> Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
> treat AtomicOps as already enabled and return success instead of
> failing the Root Port walk.
> 
> After 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port
> supports them"), pci_enable_atomic_ops_to_root() always fails if the
> Root Port is not visible.  On systems where the Root Port is not
> visible but *does* support AtomicOps, this is a regression: prior to
> 1ae8c4ce1570, it enabled AtomicOps in the endpoint and returned
> success.
> 
> Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them")
> Reviewed-by: Christian König <christian.koenig@amd.com>
> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
> Tested-by: Gerd Bayer <gbayer@linux.ibm.com>
> Signed-off-by: Nikola Prica <nikola.prica@amd.com>

Applied to pci/for-linus for v7.3, thank you!

I tweaked the last paragraph to be more explicit about the regression
behavior (as I understand it):

  After 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port
  supports them"), pci_enable_atomic_ops_to_root() always returns
  failure if the Root Port is not visible, so drivers don't use
  atomics when they could.

> ---
> v4: Updates commit log to make regression point clear
> v3: Add Fixes tag
> v2: Be more strict and only apply logic in headless device case.
> ---
>  drivers/pci/pci.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b2879a6be5f8..62729ade496f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>  	}
>  
>  	root = pcie_find_root_port(dev);
> -	if (!root)
> +	if (!root) {
> +		/*
> +		 * A hypervisor may expose a headless topology with no
> +		 * visible root port.  If it has already set AtomicOp
> +		 * Requester Enable, there is nothing more to do.
> +		 */
> +		pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
> +		if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
> +			return 0;
> +
>  		return -EINVAL;
> +	}
>  
>  	pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>  	if ((cap & cap_mask) != cap_mask)
> -- 
> 2.34.1
> 

Re: [PATCH v3] PCI: Accept AtomicOps already enabled by the hypervisor

[Christian König]

On 9/21/26 13:04, Prica, Nikola wrote:
> On 9/18/2026 7:07 PM, Bjorn Helgaas wrote:
>> On Fri, Sep 18, 2026 at 02:07:46PM +0200, Christian König wrote:
>>> On 9/18/26 11:28, Nikola Prica wrote:
>>>> From: Nikola Prica <nikola.prica@amd.com>
>>>>
>>>> pci_enable_atomic_ops_to_root() currently fails when no Root Port is
>>>> visible. That is common in passthrough guests (ESXi, Hyper-V): the
>>>> endpoint is assigned to the VM, but the guest topology has no Root
>>>> Port above it.
>>>>
>>>> In those setups the hypervisor may already have enabled AtomicOp
>>>> Requester Enable on the device. If PCI_EXP_DEVCTL2_ATOMIC_REQ is set,
>>>> treat AtomicOps as already enabled and return success instead of
>>>> failing the Root Port walk.
>>>>
>>>> Fixes: 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port supports them")
>>>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>>> Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
>>>> Tested-by: Gerd Bayer <gbayer@linux.ibm.com>
>>>> Signed-off-by: Nikola Prica <nikola.prica@amd.com>
>>>
>>> CC: stable@vger.kernel.org # 7.1+
>>>
>>> Bjorn do you want to pick that up? Alternative I can push it through
>>> drm-misc-fixes.
>>>
>>> Initially I thought that this is a new feature, but it turned out to
>>> be an regression and we need to get it fixed ASAP.
>>
>> Let me just talk through this to make sure I understand it:
>>
>> Prior to 1ae8c4ce1570, pci_enable_atomic_ops_to_root() enabled
>> PCI_EXP_DEVCTL2_ATOMIC_REQ unless a switch port didn't support
>> AtomicOp routing, a switch upstream port blocked AtomicOp egress, or a
>> Root Port didn't support the requested sizes.
>>
> 
> To be technically correct, some hypervisors do not allow guest VM to
> set the PCI_EXP_DEVCTL2_ATOMIC_REQ. So there were cases where this
> set command didn't get through. But drivers relied on return value
> of pci_enable_atomic_ops_to_root(). It may be good to read it back
> to make sure that set went through.

Well that behavior of the hypervisor is a bit questionable.

I understand why the hypervisor blocks such configuration changes, but it is essentially a recipe for trouble.

So I agree that the Linux kernel should be as defensive as possible and double check if enabling the feature really worked as expected.

>> 1ae8c4ce1570 added the requirement that the Root Port be visible,
>> which fixed an s390 case where pci_enable_atomic_ops_to_root() enabled
>> AtomicOps when the Root Port did not support them but was not visible
>> to the kernel.
>>
>> IIUC the regression is on systems where the Root Port is not visible
>> but *does* support AtomicOps.  Prior to 1ae8c4ce1570, we would have
>> enabled AtomicOps in the endpoint and returned success.  After
>> 1ae8c4ce1570, we return -EINVAL because we can't see the Root Port to
>> verify its support, so the driver thinks it can't use AtomicOps.
>>
>> This patch fixes the regression by assuming that if we can't see the
>> Root Port but the endpoint already has AtomicOps enabled, the
>> hypervisor or host kernel that *can* see the Root Port has already
>> verified its AtomicOps support, so all we have to do is return success
>> so the driver can use them.
>>
>> I'm happy to merge this for v7.3, and I think we should add something
>> like this to the commit log to make it clear that it's a regression
>> worthy of a post-merge window fix:
>>
>>    After 1ae8c4ce1570 ("PCI: Enable AtomicOps only if Root Port
>>    supports them"), pci_enable_atomic_ops_to_root() always fails if the
>>    Root Port is not visible.  On systems where the Root Port is not
>>    visible but *does* support AtomicOps, this is a regression: prior to
>>    1ae8c4ce1570, it enabled AtomicOps in the endpoint and returned
>>    success.
>>
>> Is there any problem report for the regression?  I don't see anything
>> at https://linux-regtracking.leemhuis.info/regzbot/mainline/, so my
>> guess is no.
>>
> 
> Yes. That is correct. I'll send new v4 patch with updated commit log
> that appends your suggestion.
> 
> 
> This patch fixes a regression introduced in v7.0-rc1-2-g1ae8c4ce1570.
> 
> #regzbot introduced: 1ae8c4ce1570
> #regzbot title: Breaks atomics operations for headless passthrough devices
> 
> 
> Hope that this will be enough to mark it as regression. If not please let
> me know.

I don't think we have a public visible bug report on the issue anywhere, so that should probably do it.

> One more question though, we encountered this issue with 6.8.0-138-generic
> kernel, we figured out the regression point is 6.8.0-135-generic. Since our
> validation teams are using older kernels too, is it safe to assume that
> fix will be backported in new release for 6.8.0-*-generic version?

That is what the Fixes: tag takes care of. Most likely the kernel 6.8.0-135-generic doesn't work because the offending commit was back ported as fix.

So when the Fixes tag identifies that commit the stable maintainers should backport it as well.

Regards,
Christian.

> 
> Regards,
> Nikola
> 
> 
>>>> ---
>>>> v3: Add Fixes tag
>>>> v2: Be more strict and only apply logic in headless device case.
>>>> ---
>>>>   drivers/pci/pci.c | 12 +++++++++++-
>>>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>>> index b2879a6be5f8..62729ade496f 100644
>>>> --- a/drivers/pci/pci.c
>>>> +++ b/drivers/pci/pci.c
>>>> @@ -3769,8 +3769,18 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
>>>>       }
>>>>         root = pcie_find_root_port(dev);
>>>> -    if (!root)
>>>> +    if (!root) {
>>>> +        /*
>>>> +         * A hypervisor may expose a headless topology with no
>>>> +         * visible root port.  If it has already set AtomicOp
>>>> +         * Requester Enable, there is nothing more to do.
>>>> +         */
>>>> +        pcie_capability_read_dword(dev, PCI_EXP_DEVCTL2, &ctl2);
>>>> +        if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_REQ)
>>>> +            return 0;
>>>> +
>>>>           return -EINVAL;
>>>> +    }
>>>>         pcie_capability_read_dword(root, PCI_EXP_DEVCAP2, &cap);
>>>>       if ((cap & cap_mask) != cap_mask)
>>>
> 

Re: [PATCH v3] PCI: Accept AtomicOps already enabled by the hypervisor

[Thorsten Leemhuis]

On 9/21/26 13:04, Prica, Nikola wrote:
> This patch fixes a regression introduced in v7.0-rc1-2-g1ae8c4ce1570.
> 
> #regzbot introduced: 1ae8c4ce1570
> #regzbot title: Breaks atomics operations for headless passthrough devices

Thanks for that

> One more question though, we encountered this issue with 6.8.0-138-generic
> kernel, we figured out the regression point is 6.8.0-135-generic. Since our
> validation teams are using older kernels too, is it safe to assume that
> fix will be backported in new release for 6.8.0-*-generic version?

To make life a bit easier for the maintainers I'll answer this: 6.8 is
EOL for years now when it comes to kernel.org aka "upstream". So only
the vendor that still maintains a kernel based on that version can
answer that question (I suspect that's Canonical).

Ciao, Thorsten