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@xxxxxxxxxx> 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@xxxxxxxxxxx>

Thanks, Alex!