On 9/18/2026, Tantilov, Emil S wrote: > This alone would not be enough, you need to make sure the reset handling > does not trigger in the driver. Sashiko is also marking it: > you will have to set IDPF_REMOVE_IN_PROG, though I am not sure if that > alone would be sufficient.
You are right, and so is the review bot. I missed it because our hardware takes the PF path. On the VF path idpf_vf_trigger_reset() sends VIRTCHNL2_OP_RESET_VF unless IDPF_REMOVE_IN_PROG is set, and idpf_shutdown() calls idpf_deinit_dflt_mbx() immediately after the trigger, which frees the ASQ while that message is still outstanding. That is an enqueue-then-free of DMA memory, and on a system with the IOMMU translating it is exactly the class of fault this series is trying to remove. On the PF path idpf_trigger_reset() only writes PFGEN_CTRL, which is why our testing never hit it. I will drop this patch from v2 rather than paper over it with a flag. It was never load bearing: the stray writes are stopped by patch 1, and this one only restored parity with idpf_remove(). If it turns out to be worth having, it belongs in its own series with the VF path handled properly. Thanks for catching it.
