Re: [PATCH v4 2/3] PCI: Add soft reset method as last resort

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] pci_soft_reset() falsely reports a successful reset for NoSoftRst+ devices, destroying hardware isolation guarantees for VFIO passthrough.
- [High] pci_soft_reset() bypasses the PCI_DEV_FLAGS_NO_PM_RESET quirk, forcing unprotected hardware power state transitions on vulnerable devices.
--

commit 9f864e1927975542a72967bb27f8a02e42ade61b
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

PCI: Add soft reset method as last resort

This commit adds a software-initiated reset method that attempts a D3hot to D0
transition as a last resort when all other reset methods fail. It extracts the
transition logic into a shared helper function used by both the standard power
management reset and the new fallback soft reset.

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 839903b596982..970928d09fe19 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
[ ... ]
> @@ -4491,6 +4474,38 @@ static int pci_pm_reset(struct pci_dev *dev, bool probe)
>  	return ret;
>  }
>  
> +/**
> + * pci_pm_reset - Put device into PCI_D3 and back into PCI_D0.
[ ... ]
> +static int pci_pm_reset(struct pci_dev *dev, bool probe)
> +{
> +	u16 csr;
> +
> +	if (!dev->pm_cap || dev->dev_flags & PCI_DEV_FLAGS_NO_PM_RESET)
> +		return -ENOTTY;
[ ... ]
> @@ -4530,6 +4545,42 @@ static int pci_d3cold_reset(struct pci_dev *dev, bool probe)
>  	return pci_set_power_state(dev, PCI_D0);
>  }
>  
> +/**
> + * pci_soft_reset - Software-initiated reset via D3hot as last resort
[ ... ]
> +static int pci_soft_reset(struct pci_dev *dev, bool probe)
> +{
> +	if (pci_pm_reset(dev, true) == 0)
> +		return -ENOTTY;
> +
> +	if (pci_d3cold_reset(dev, true) == 0)
> +		return -ENOTTY;
> +
> +	if (!dev->pm_cap)
> +		return -ENOTTY;
> +
> +	if (probe)
> +		return 0;
> +
> +	return pci_do_d3hot_transition(dev);
> +}

Does this sequence introduce a regression by bypassing the
PCI_DEV_FLAGS_NO_PM_RESET quirk?

When pci_pm_reset() is called with probe set to true, it returns -ENOTTY if
the device has the PCI_DEV_FLAGS_NO_PM_RESET flag set. Since -ENOTTY is not 0,
pci_soft_reset() will proceed and unconditionally execute
pci_do_d3hot_transition().

Could this force a power state transition on vulnerable devices that were
explicitly blacklisted from power management resets?

Additionally, does bypassing the NoSoftRst check globally introduce a
regression in device sanitization for compliant hardware?

The PCI specification defines the NoSoftRst bit to indicate that a device
retains its internal state during a D3hot to D0 transition. If a compliant
device correctly implements NoSoftRst set to 1, this fallback method will
falsely report a successful reset without actually scrubbing the device
context.

Since security boundaries like VFIO passthrough rely on pci_reset_function()
to guarantee complete device sanitization between VMs, can this global
fallback allow state contamination or data leaks?

Would it be safer to handle devices that incorrectly advertise NoSoftRst via
device-specific quirks instead of a global bypass?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518124836.460805-1-jtornosm@redhat.com?part=2