On Tue, Nov 11, 2025 at 02:38:19AM +0100, Tian, Kevin wrote:
> > From: Winiarski, Michal <[email protected]>
> > Sent: Tuesday, November 11, 2025 9:05 AM
> > +
> > +   /*
> > +    * As the higher VFIO layers are holding locks across reset and using
> > +    * those same locks with the mm_lock we need to prevent ABBA
> > deadlock
> > +    * with the state_mutex and mm_lock.
> > +    * In case the state_mutex was taken already we defer the cleanup
> > work
> > +    * to the unlock flow of the other running context.
> > +    */
> > +   spin_lock(&xe_vdev->reset_lock);
> > +   xe_vdev->deferred_reset = true;
> > +   if (!mutex_trylock(&xe_vdev->state_mutex)) {
> > +           spin_unlock(&xe_vdev->reset_lock);
> > +           return;
> > +   }
> > +   spin_unlock(&xe_vdev->reset_lock);
> > +   xe_vfio_pci_state_mutex_unlock(xe_vdev);
> > +
> > +   xe_vfio_pci_reset(xe_vdev);
> > +}
> 
> Jason suggested to do this in the core given it's common [1].
> 
> If you disagree, then please raise it and get consensus in that thread
> instead of rushing to post a new version...
> 
> [1] https://lore.kernel.org/all/[email protected]/

Hi,

I agree that it should be done in the core eventually.
I didn't view it as something blocking next revision, as the discussion
was in the context of converting every driver, which is something that
probably shouldn't be done as part of this series.

Note that the v6.19 feature pull for Xe is likely going to happen
tomorrow, so that's part of the reason for "rushing" the next version.
I wanted to collect all the r-bs on Xe side to be prepared for that.
If any parts of this series need to go through Xe tree, it will need to
be merged there soon (or wait all the way until v6.20 / v7).

Thanks,
-Michał

Reply via email to