Re: [PATCH v3 1/2] PCI: Add D3cold as general reset method

[Jose Ignacio Tornos Martinez]

Hello Alex,

Thank you again for the detailed feedback.

> Are you testing with the patch that marks these devices
> PCI_DEV_FLAGS_NO_BUS_RESET?
Yes, I'm testing with quirk_no_bus_reset applied.
My evidence about bus issues with the commented Qualcomm cards is
device-specific and not adapter-specific because we are using the same
adapter with the commented MediaTek MT7925e
- Uses quirk_no_flr (https://lore.kernel.org/all/20260511123936.36054-1-jtornosm@xxxxxxxxxx/)
- reset_method shows: "bus"
- Bus reset works correctly for VFIO passthrough reuse
This proves PERST# is properly wired through the passive adapters. Since
Qualcomm devices fail SBR with the same adapter setup where MediaTek
succeeds, I think the issue is device-specific, not deployment-specific.

> I want to be sure that bouncing the device
> through D3hot is actually an improvement versus no reset at all, and
> we're not just performing a no-op reset to avoid the bus reset.
The D3hot transition is definitely an improvement over no reset at all:
- Without any reset: Device remains in undefined state after VM crash and
  cannot be reused.
- With D3hot transition: Command register gets cleared (0x0002 → 0x0000),
  device can be reinitialized and successfully assigned to the VM
Testing methodology: VM crash → check PCI config space → verify device
reusable. The D3hot transition clears enough state for VFIO passthrough
reuse, even though it's not a full FLR-style reset.

> That said, if you're testing before BAR restore and those registers
> aren't being cleared, this seems at best a device specific reset, but
> evidence is a bit sketchy. In the general case, a transition through
> D3hot for a device that does not claim NoSoftRst- cannot be consider to
> satisfy a reset request.
Agree, my testing confirms:
- Command register: CLEARED (0x0002 → 0x0000 → 0x0506 after driver init)
- BARs: PRESERVED (0x84200004 maintained throughout)
So, this is a partial reset, not a full spec-compliant reset and only the
command register is cleared. However it works.

> If you can block the known broken resets and manage to trigger a D3hot
> transition externally, that may provide a reasonably useful environment.
> We've also been known to implement the sketchier resets that can't fully
> be justified as a kernel quirk in QEMU itself.
I understand the concern about sketchy resets in the kernel. 
I have prepared v4 version with a different conservative approach not
changing anything in the current behavior, as a last resort and only adding
a "soft" method when other reset methods are not available (our current case
for Qualcomm cards).
I believe providing it as optional kernel infrastructure (user-controllable
via sysfs) has value because:
  - Benefits all VMMs (QEMU, cloud-hypervisor, etc.), not just QEMU
  - Uses standard PCI PM mechanisms, no device-specific hacks
  - Provides measurable value for VFIO passthrough where no reset exists
Happy to adjust based on your feedback

Thanks

Best regards
José Ignacio