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

[sashiko-bot@kernel.org]

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