[PATCH v14 0/2] PCI: Add device-specific reset for Qualcomm devices

[PATCH v14 0/2] PCI: Add device-specific reset for Qualcomm devices

[Jose Ignacio Tornos Martinez]

Some Qualcomm PCIe devices (WCN6855, WCN7850 WLAN; SDX62/SDX65 modems)
lack working reset methods for VFIO passthrough scenarios. These devices
have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
broken bus reset (addressed by quirk_no_bus_reset, merged for v7.2).

VFIO attempts to reset devices on every reassignment:
- For the listed modems, without a proper reset capability, these devices
never successfully initialize even on first VM assignment.
- For the listed WLAN devices, without a working reset method, the attempt
fails. On clean VM shutdown, the guest driver properly deinitializes the
device via .shutdown/.remove callbacks, leaving it in a usable state despite
the failed reset. However, on unclean VM termination (crash, force-off), the
guest driver callbacks are not triggered, the device remains in an undefined
state (DMA active, interrupts enabled, etc.), and without a working reset it
cannot be reused.

Add device-specific reset methods using BAR-space hardware reset registers
that exist in these devices:

  Patch 1: SDX62/SDX65 modem reset via MHI SoC reset
  Patch 2: WCN6855/WCN7850 WLAN reset via SoC global reset

These are true hardware reset mechanisms (not power management or firmware
error recovery), providing proper device reset for VFIO scenarios.

Testing shows stable operation over 100+ VM crash/reset cycles. Device-
specific reset is position #1 in the reset hierarchy, so these devices
will use hardware reset as their primary reset method.

Jose Ignacio Tornos Martinez (2):
  PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems
  PCI: Add device-specific reset for Qualcomm WCN6855/WCN7850 WLAN

 drivers/pci/quirks.c | 116 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 116 insertions(+)

---
v14: Address Bjorn Helgaas feedback:
  - Split WLAN and modem resets into two separate patches
  - Clarify commit message for WLAN devices: VFIO resets on every
    reassignment, clean shutdown leaves device in usable state via
    driver callbacks, but unclean termination is where the lack of reset
    is critical
  - No code changes from v13, only patch split and commit message
    clarification (Mani's Reviewed-by retained)
v13: https://lore.kernel.org/all/20260915223634.GA878346@bhelgaas/

--
2.54.0

[PATCH v14 1/2] PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems

[Jose Ignacio Tornos Martinez]

Qualcomm SDX62/SDX65 5G modems (17cb:0308) lack working reset methods for
VFIO passthrough scenarios. These devices have no FLR capability, advertise
NoSoftRst+ (blocking PM reset), and have broken bus reset (addressed by
quirk_no_bus_reset, merged for v7.2).

VFIO attempts to reset devices on every reassignment. Without a proper
reset capability, these devices never successfully initialize even on first
VM assignment.

Add a device-specific reset method using BAR-space hardware reset registers
that exist in these devices.

SDX62/SDX65 modem devices use MHI SoC reset via BAR0 (sequence from MHI
driver: mhi_soc_reset(), mhi_pci_reset_prepare()):
- Write reset request to offset 0xb0
- Wait 2 seconds for reset completion

This is a true hardware reset mechanism (not power management or firmware
error recovery), providing proper device reset for VFIO scenarios.

Testing shows stable operation over 109 VM crash/reset cycles. Device-
specific reset is position #1 in the reset hierarchy, so these Qualcomm
devices will use hardware reset as their primary reset method.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
v14: Address Bjorn Helgaas feedback:
  - Split WLAN and modem resets into two separate patches
  - No code changes from v13, only patch split and commit message
    clarification (Mani's Reviewed-by retained)
v13: https://lore.kernel.org/all/20260915223634.GA878346@bhelgaas/

 drivers/pci/quirks.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index de9bbccda21f..e72af7d2c775 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4230,6 +4230,45 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
 	return 0;
 }
 
+#define MHI_SOC_RESET_REQ_OFFSET		0xb0
+#define MHI_SOC_RESET_REQ			BIT(0)
+
+/*
+ * Qualcomm modem device-specific reset using MHI SoC reset via BAR0
+ * register.
+ */
+static int reset_qualcomm_modem(struct pci_dev *pdev, bool probe)
+{
+	void __iomem *bar;
+	u16 cmd;
+
+	if (probe)
+		return 0;
+
+	if (pdev->current_state != PCI_D0)
+		return -EINVAL;
+
+	pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
+
+	bar = pci_iomap(pdev, 0, 0);
+	if (!bar) {
+		pci_write_config_word(pdev, PCI_COMMAND, cmd);
+		return -ENODEV;
+	}
+
+	iowrite32(MHI_SOC_RESET_REQ, bar + MHI_SOC_RESET_REQ_OFFSET);
+	ioread32(bar + MHI_SOC_RESET_REQ_OFFSET);
+
+	/* Be sure device reset has been executed */
+	msleep(2000);
+
+	pci_iounmap(pdev, bar);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+	return 0;
+}
+
 static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
 		 reset_intel_82599_sfp_virtfn },
@@ -4245,6 +4284,7 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 		reset_chelsio_generic_dev },
 	{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
 		reset_hinic_vf_dev },
+	{ PCI_VENDOR_ID_QCOM, 0x0308, reset_qualcomm_modem }, /* SDX62/SDX65 modems */
 	{ 0 }
 };
 
-- 
2.54.0

[PATCH v14 2/2] PCI: Add device-specific reset for Qualcomm WCN6855/WCN7850 WLAN

[Jose Ignacio Tornos Martinez]

Qualcomm WCN6855 (17cb:1103) and WCN7850 (17cb:1107) WLAN devices lack
working reset methods for VFIO passthrough scenarios. These devices have no
FLR capability, advertise NoSoftRst+ (blocking PM reset), and have broken
bus reset (addressed by quirk_no_bus_reset, merged for v7.2).

VFIO attempts to reset devices on every reassignment. Without a working
reset method, the attempt fails. On clean VM shutdown, the guest driver
properly deinitializes the device via .shutdown/.remove callbacks, leaving
it in a usable state despite the failed reset. However, on unclean VM
termination (crash, force-off), the guest driver callbacks are not
triggered, the device remains in an undefined state (DMA active, interrupts
enabled, etc.), and without a working reset it cannot be reused.

Add a device-specific reset method using BAR-space hardware reset registers
that exist in these devices.

WCN6855/WCN7850 WLAN devices use SoC global reset via BAR0 (sequence from
ath11k/ath12k driver: ath11k_pci_soc_global_reset(), ath11k_pci_sw_reset(),
ath11k_mhi_set_mhictrl_reset()):
- Write/clear reset bit at offset 0x3008
- Wait for PCIe link recovery (up to 5 seconds)
- Clear MHI controller SYSERR status at offset 0x38

This is a true hardware reset mechanism (not power management or firmware
error recovery), providing proper device reset for VFIO scenarios.

Testing shows stable operation over 100+ VM crash/reset cycles, compared
to previous approaches that failed after ~30 cycles. Device-specific reset
is position #1 in the reset hierarchy, so these Qualcomm devices will use
hardware reset as their primary reset method.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
v14: Address Bjorn Helgaas feedback:
  - Split WLAN and modem resets into two separate patches
  - Clarify commit message: VFIO resets on every reassignment, clean
    shutdown leaves device in usable state via driver callbacks, but
    unclean termination is where the lack of reset is critical
  - No code changes from v13, only patch split and commit message
    clarification (Mani's Reviewed-by retained)
v13: https://lore.kernel.org/all/20260915223634.GA878346@bhelgaas/

 drivers/pci/quirks.c | 76 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e72af7d2c775..e800dd517614 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -22,6 +22,7 @@
 #include <linux/isa-dma.h> /* isa_dma_bridge_buggy */
 #include <linux/init.h>
 #include <linux/iommu.h>
+#include <linux/iopoll.h>
 #include <linux/delay.h>
 #include <linux/acpi.h>
 #include <linux/dmi.h>
@@ -4230,6 +4231,79 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
 	return 0;
 }
 
+#define QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET	0x3008
+#define QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V	BIT(0)
+#define QUALCOMM_WLAN_MHICTRL			0x38
+#define QUALCOMM_WLAN_MHICTRL_RESET_MASK	0x2
+
+/*
+ * Qualcomm WLAN device-specific reset using SoC global reset via BAR0
+ * registers.
+ */
+static int reset_qualcomm_wlan(struct pci_dev *pdev, bool probe)
+{
+	void __iomem *bar;
+	u32 val;
+	u16 cmd;
+	int ret;
+
+	if (probe)
+		return 0;
+
+	if (pdev->current_state != PCI_D0)
+		return -EINVAL;
+
+	pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
+
+	bar = pci_iomap(pdev, 0, 0);
+	if (!bar) {
+		pci_write_config_word(pdev, PCI_COMMAND, cmd);
+		return -ENODEV;
+	}
+
+	val = ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+	if (PCI_POSSIBLE_ERROR(val)) {
+		ret = -ENODEV;
+		goto out_restore;
+	}
+	val |= QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V;
+	iowrite32(val, bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+	ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+
+	msleep(10);
+
+	val &= ~QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V;
+	iowrite32(val, bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+	ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+
+	msleep(10);
+
+	ret = read_poll_timeout(ioread32, val,
+				!PCI_POSSIBLE_ERROR(val),
+				20 * USEC_PER_MSEC,
+				5 * USEC_PER_SEC, false,
+				bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+	if (ret) {
+		pci_err(pdev, "PCIe link failed to recover after reset\n");
+		goto out_restore;
+	}
+
+	/* After SOC_GLOBAL_RESET, MHISTATUS may still have SYSERR bit set
+	 * and thus need to set MHICTRL_RESET to clear SYSERR.
+	 */
+	iowrite32(QUALCOMM_WLAN_MHICTRL_RESET_MASK, bar + QUALCOMM_WLAN_MHICTRL);
+	ioread32(bar + QUALCOMM_WLAN_MHICTRL);
+
+	msleep(10);
+
+out_restore:
+	pci_iounmap(pdev, bar);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+	return ret;
+}
+
 #define MHI_SOC_RESET_REQ_OFFSET		0xb0
 #define MHI_SOC_RESET_REQ			BIT(0)
 
@@ -4285,6 +4359,8 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 	{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
 		reset_hinic_vf_dev },
 	{ PCI_VENDOR_ID_QCOM, 0x0308, reset_qualcomm_modem }, /* SDX62/SDX65 modems */
+	{ PCI_VENDOR_ID_QCOM, 0x1103, reset_qualcomm_wlan },  /* WCN6855 WLAN */
+	{ PCI_VENDOR_ID_QCOM, 0x1107, reset_qualcomm_wlan },  /* WCN7850 WLAN */
 	{ 0 }
 };
 
-- 
2.54.0

Re: [PATCH v14 2/2] PCI: Add device-specific reset for Qualcomm WCN6855/WCN7850 WLAN

[sashiko-bot]

> Qualcomm WCN6855 (17cb:1103) and WCN7850 (17cb:1107) WLAN devices lack
> working reset methods for VFIO passthrough scenarios. These devices have no
> FLR capability, advertise NoSoftRst+ (blocking PM reset), and have broken
> bus reset (addressed by quirk_no_bus_reset, merged for v7.2).
> 
> VFIO attempts to reset devices on every reassignment. Without a working
> reset method, the attempt fails. On clean VM shutdown, the guest driver
> properly deinitializes the device via .shutdown/.remove callbacks, leaving
> it in a usable state despite the failed reset. However, on unclean VM
> termination (crash, force-off), the guest driver callbacks are not
> triggered, the device remains in an undefined state (DMA active, interrupts
> enabled, etc.), and without a working reset it cannot be reused.
> 
> Add a device-specific reset method using BAR-space hardware reset registers
> that exist in these devices.
> [ ... ]
> to previous approaches that failed after ~30 cycles. Device-specific reset
> is position #1 in the reset hierarchy, so these Qualcomm devices will use
> hardware reset as their primary reset method.
> 
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

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

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

Re: [PATCH v14 1/2] PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: reset_qualcomm_modem re-enables memory decoding with zeroed BARs
--

commit 697e75cacc91e92df3d44b2fa95b07329f110e59
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems

Qualcomm SDX62/SDX65 5G modems lack working reset methods for VFIO
passthrough. This commit adds a device-specific reset method for them using
MHI SoC reset via BAR0. The reset method writes to a hardware reset
register and waits for completion.

> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index de9bbccda21fd..e72af7d2c7755 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c

[ ... ]

> +static int reset_qualcomm_modem(struct pci_dev *pdev, bool probe)
> +{
> +	void __iomem *bar;
> +	u16 cmd;
> +
> +	if (probe)
> +		return 0;
> +
> +	if (pdev->current_state != PCI_D0)
> +		return -EINVAL;
> +
> +	pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> +	pci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
> +
> +	bar = pci_iomap(pdev, 0, 0);
> +	if (!bar) {
> +		pci_write_config_word(pdev, PCI_COMMAND, cmd);
> +		return -ENODEV;
> +	}
> +
> +	iowrite32(MHI_SOC_RESET_REQ, bar + MHI_SOC_RESET_REQ_OFFSET);
> +	ioread32(bar + MHI_SOC_RESET_REQ_OFFSET);
> +
> +	/* Be sure device reset has been executed */
> +	msleep(2000);
> +
> +	pci_iounmap(pdev, bar);
> +	pci_write_config_word(pdev, PCI_COMMAND, cmd);

[Severity: High]
Does this unsafely enable memory decoding on a hardware-reset device with
zeroed BARs?

If the caller did not explicitly clear PCI_COMMAND_MEMORY before the reset,
cmd will have PCI_COMMAND_MEMORY set.

The hardware reset zeroes the device's PCI configuration space, including all
BARs. Restoring cmd with PCI_COMMAND_MEMORY set will immediately enable memory
decoding while the BARs are still 0, potentially causing severe PCIe bus
conflicts, IOMMU faults, or kernel panics since the device will intercept
memory accesses to physical address 0.

Should we clear PCI_COMMAND_MEMORY before returning (e.g.,
cmd & ~PCI_COMMAND_MEMORY), relying on the caller's subsequent
pci_restore_state() to safely reprogram the BARs before memory decoding is
formally re-enabled?

> +
> +	return 0;
> +}

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

Re: [PATCH v14 1/2] PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems

[Jose Ignacio Tornos Martinez]

> [Severity: High]
> Does this unsafely enable memory decoding on a hardware-reset device with
> zeroed BARs?
>
> If the caller did not explicitly clear PCI_COMMAND_MEMORY before the reset,
> cmd will have PCI_COMMAND_MEMORY set.
>
> The hardware reset zeroes the device's PCI configuration space, including all
> BARs. Restoring cmd with PCI_COMMAND_MEMORY set will immediately enable memory
> decoding while the BARs are still 0, potentially causing severe PCIe bus
> conflicts, IOMMU faults, or kernel panics since the device will intercept
> memory accesses to physical address 0.
>
> Should we clear PCI_COMMAND_MEMORY before returning (e.g.,
> cmd & ~PCI_COMMAND_MEMORY), relying on the caller's subsequent
> pci_restore_state() to safely reprogram the BARs before memory decoding is
> formally re-enabled?

The MHI SoC reset is a device-internal firmware/SoC reset, not a PCI-level
reset. It does not zero the PCI configuration space or BARs, the PCIe link
stays alive during this reset and BARs are maintained by the host PCI
subsystem.

Additionally, the PCI reset framework calls pci_dev_save_and_disable()
before and pci_dev_restore() after the reset method, so config space is
properly managed by the caller.

The reset sequence replicates the existing MHI driver code (mhi_soc_reset(),
mhi_pci_reset_prepare()) which works in production.

Re: [PATCH v14 0/2] PCI: Add device-specific reset for Qualcomm devices

[Bjorn Helgaas]

[cc->to: Alex, +cc Jason]

On Thu, Sep 17, 2026 at 09:16:49AM +0200, Jose Ignacio Tornos Martinez wrote:
> Some Qualcomm PCIe devices (WCN6855, WCN7850 WLAN; SDX62/SDX65 modems)
> lack working reset methods for VFIO passthrough scenarios. These devices
> have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
> broken bus reset (addressed by quirk_no_bus_reset, merged for v7.2).

Specifically, 6a4f64c3a3ad ("PCI: Avoid SBR for Qualcomm
WCN6855/WCN7850 WiFi, SDX62/SDX65 modems").  I don't know what the
behavior was prior to that commit.  I suppose it was something
obvious?

> VFIO attempts to reset devices on every reassignment:
> - For the listed modems, without a proper reset capability, these devices
> never successfully initialize even on first VM assignment.
> - For the listed WLAN devices, without a working reset method, the attempt
> fails. On clean VM shutdown, the guest driver properly deinitializes the
> device via .shutdown/.remove callbacks, leaving it in a usable state despite
> the failed reset. However, on unclean VM termination (crash, force-off), the
> guest driver callbacks are not triggered, the device remains in an undefined
> state (DMA active, interrupts enabled, etc.), and without a working reset it
> cannot be reused.

So IIUC, prior to these patches, these devices were functional when
passed through to several successive guests as long as the guests shut
down cleanly, but the resets done by VFIO didn't work, so the host
couldn't enforce isolation between those guests.

If true, I propose updating the commit logs to emphasize the lack of
isolation and de-emphasize the VM clean shutdown vs crash behavior,
e.g.:

  Resets of this device always failed prior to this commit, so VFIO on
  the host could not enforce isolation between successive passthrough
  users.

  If a guest driver deinitialized the device, it may have been
  functional if passed through to a subsequent guest, despite the lack
  of isolation.  Otherwise the device may have been left in an
  undefined state (e.g., DMA and interrupts active) and unusable.

It would also be great to have Alex's ack here.

> Add device-specific reset methods using BAR-space hardware reset registers
> that exist in these devices:
> 
>   Patch 1: SDX62/SDX65 modem reset via MHI SoC reset
>   Patch 2: WCN6855/WCN7850 WLAN reset via SoC global reset
> 
> These are true hardware reset mechanisms (not power management or firmware
> error recovery), providing proper device reset for VFIO scenarios.
> 
> Testing shows stable operation over 100+ VM crash/reset cycles. Device-
> specific reset is position #1 in the reset hierarchy, so these devices
> will use hardware reset as their primary reset method.
> 
> Jose Ignacio Tornos Martinez (2):
>   PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems
>   PCI: Add device-specific reset for Qualcomm WCN6855/WCN7850 WLAN
> 
>  drivers/pci/quirks.c | 116 +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 116 insertions(+)
> 
> ---
> v14: Address Bjorn Helgaas feedback:
>   - Split WLAN and modem resets into two separate patches
>   - Clarify commit message for WLAN devices: VFIO resets on every
>     reassignment, clean shutdown leaves device in usable state via
>     driver callbacks, but unclean termination is where the lack of reset
>     is critical
>   - No code changes from v13, only patch split and commit message
>     clarification (Mani's Reviewed-by retained)
> v13: https://lore.kernel.org/all/20260915223634.GA878346@bhelgaas/
> 
> --
> 2.54.0
> 

Re: [PATCH v14 0/2] PCI: Add device-specific reset for Qualcomm devices

[Alex Williamson]

On Fri, 2 Oct 2026 16:40:58 -0500
Bjorn Helgaas <helgaas@kernel.org> wrote:

> [cc->to: Alex, +cc Jason]
> 
> On Thu, Sep 17, 2026 at 09:16:49AM +0200, Jose Ignacio Tornos Martinez wrote:
> > Some Qualcomm PCIe devices (WCN6855, WCN7850 WLAN; SDX62/SDX65 modems)
> > lack working reset methods for VFIO passthrough scenarios. These devices
> > have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
> > broken bus reset (addressed by quirk_no_bus_reset, merged for v7.2).  
> 
> Specifically, 6a4f64c3a3ad ("PCI: Avoid SBR for Qualcomm
> WCN6855/WCN7850 WiFi, SDX62/SDX65 modems").  I don't know what the
> behavior was prior to that commit.  I suppose it was something
> obvious?
> 
> > VFIO attempts to reset devices on every reassignment:
> > - For the listed modems, without a proper reset capability, these devices
> > never successfully initialize even on first VM assignment.
> > - For the listed WLAN devices, without a working reset method, the attempt
> > fails. On clean VM shutdown, the guest driver properly deinitializes the
> > device via .shutdown/.remove callbacks, leaving it in a usable state despite
> > the failed reset. However, on unclean VM termination (crash, force-off), the
> > guest driver callbacks are not triggered, the device remains in an undefined
> > state (DMA active, interrupts enabled, etc.), and without a working reset it
> > cannot be reused.  
> 
> So IIUC, prior to these patches, these devices were functional when
> passed through to several successive guests as long as the guests shut
> down cleanly, but the resets done by VFIO didn't work, so the host
> couldn't enforce isolation between those guests.
> 
> If true, I propose updating the commit logs to emphasize the lack of
> isolation and de-emphasize the VM clean shutdown vs crash behavior,
> e.g.:
> 
>   Resets of this device always failed prior to this commit, so VFIO on
>   the host could not enforce isolation between successive passthrough
>   users.
> 
>   If a guest driver deinitialized the device, it may have been
>   functional if passed through to a subsequent guest, despite the lack
>   of isolation.  Otherwise the device may have been left in an
>   undefined state (e.g., DMA and interrupts active) and unusable.
> 
> It would also be great to have Alex's ack here.

Yes, aiui it's an isolation and repeatability issue.  In fact, without
knowing what's actually stored in the hardware, I'd suspect it's more
the latter and the testing proves that.  Mani is really the one
vouching for it from the hardware, isolation perspective.

Standard reset methods have never worked on these devices and that's
now evident by the quirks that disable them for these devices.  This
fills the remaining gap by providing device specific resets for the same
hardware.

Both patches should properly reference the quirk_no_bus_reset commit,
but otherwise these look correct, afaict.

Acked-by: Alex Williamson <alex@shazbot.org>

Thanks,
Alex
 
> > Add device-specific reset methods using BAR-space hardware reset registers
> > that exist in these devices:
> > 
> >   Patch 1: SDX62/SDX65 modem reset via MHI SoC reset
> >   Patch 2: WCN6855/WCN7850 WLAN reset via SoC global reset
> > 
> > These are true hardware reset mechanisms (not power management or firmware
> > error recovery), providing proper device reset for VFIO scenarios.
> > 
> > Testing shows stable operation over 100+ VM crash/reset cycles. Device-
> > specific reset is position #1 in the reset hierarchy, so these devices
> > will use hardware reset as their primary reset method.
> > 
> > Jose Ignacio Tornos Martinez (2):
> >   PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems
> >   PCI: Add device-specific reset for Qualcomm WCN6855/WCN7850 WLAN
> > 
> >  drivers/pci/quirks.c | 116 +++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 116 insertions(+)
> > 
> > ---
> > v14: Address Bjorn Helgaas feedback:
> >   - Split WLAN and modem resets into two separate patches
> >   - Clarify commit message for WLAN devices: VFIO resets on every
> >     reassignment, clean shutdown leaves device in usable state via
> >     driver callbacks, but unclean termination is where the lack of reset
> >     is critical
> >   - No code changes from v13, only patch split and commit message
> >     clarification (Mani's Reviewed-by retained)
> > v13: https://lore.kernel.org/all/20260915223634.GA878346@bhelgaas/
> > 
> > --
> > 2.54.0
> >   

Re: [PATCH v14 0/2] PCI: Add device-specific reset for Qualcomm devices

[Bjorn Helgaas]

On Fri, Oct 02, 2026 at 05:09:49PM -0600, Alex Williamson wrote:
> On Fri, 2 Oct 2026 16:40:58 -0500
> Bjorn Helgaas <helgaas@kernel.org> wrote:
> 
> > [cc->to: Alex, +cc Jason]
> > 
> > On Thu, Sep 17, 2026 at 09:16:49AM +0200, Jose Ignacio Tornos Martinez wrote:
> > > Some Qualcomm PCIe devices (WCN6855, WCN7850 WLAN; SDX62/SDX65 modems)
> > > lack working reset methods for VFIO passthrough scenarios. These devices
> > > have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
> > > broken bus reset (addressed by quirk_no_bus_reset, merged for v7.2).  
> > 
> > Specifically, 6a4f64c3a3ad ("PCI: Avoid SBR for Qualcomm
> > WCN6855/WCN7850 WiFi, SDX62/SDX65 modems").  I don't know what the
> > behavior was prior to that commit.  I suppose it was something
> > obvious?
> > 
> > > VFIO attempts to reset devices on every reassignment:
> > > - For the listed modems, without a proper reset capability, these devices
> > > never successfully initialize even on first VM assignment.
> > > - For the listed WLAN devices, without a working reset method, the attempt
> > > fails. On clean VM shutdown, the guest driver properly deinitializes the
> > > device via .shutdown/.remove callbacks, leaving it in a usable state despite
> > > the failed reset. However, on unclean VM termination (crash, force-off), the
> > > guest driver callbacks are not triggered, the device remains in an undefined
> > > state (DMA active, interrupts enabled, etc.), and without a working reset it
> > > cannot be reused.  
> > 
> > So IIUC, prior to these patches, these devices were functional when
> > passed through to several successive guests as long as the guests shut
> > down cleanly, but the resets done by VFIO didn't work, so the host
> > couldn't enforce isolation between those guests.
> > 
> > If true, I propose updating the commit logs to emphasize the lack of
> > isolation and de-emphasize the VM clean shutdown vs crash behavior,
> > e.g.:
> > 
> >   Resets of this device always failed prior to this commit, so VFIO on
> >   the host could not enforce isolation between successive passthrough
> >   users.
> > 
> >   If a guest driver deinitialized the device, it may have been
> >   functional if passed through to a subsequent guest, despite the lack
> >   of isolation.  Otherwise the device may have been left in an
> >   undefined state (e.g., DMA and interrupts active) and unusable.
> > 
> > It would also be great to have Alex's ack here.
> 
> Yes, aiui it's an isolation and repeatability issue.  In fact, without
> knowing what's actually stored in the hardware, I'd suspect it's more
> the latter and the testing proves that.  Mani is really the one
> vouching for it from the hardware, isolation perspective.
> 
> Standard reset methods have never worked on these devices and that's
> now evident by the quirks that disable them for these devices.  This
> fills the remaining gap by providing device specific resets for the same
> hardware.
> 
> Both patches should properly reference the quirk_no_bus_reset commit,
> but otherwise these look correct, afaict.
> 
> Acked-by: Alex Williamson <alex@shazbot.org>

Thanks, Alex!

Re: [PATCH v14 0/2] PCI: Add device-specific reset for Qualcomm devices

[Jose Ignacio Tornos Martinez]

Thanks Bjorn for the feedback, and thanks Alex for the Acked-by.

I'll send v15 with the commit messages updated as suggested,
emphasizing isolation and referencing 6a4f64c3a3ad.

Best regards
José Ignacio