linux-kernel - Re: [PATCH v5 28/28] vfio/xe: Add device specific vfio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ndd4kt4elbm7ixzyouhorgatjwv73ldyjo6bmrbipxvaqzccjs@ssavf6b5ric3>
Date: Wed, 12 Nov 2025 14:46:08 +0100
From: "Winiarski, Michal" <michal.winiarski@...el.com>
To: "Tian, Kevin" <kevin.tian@...el.com>, Jason Gunthorpe <jgg@...pe.ca>
CC: Alex Williamson <alex@...zbot.org>, "De Marchi, Lucas"
	<lucas.demarchi@...el.com>, Thomas Hellström
	<thomas.hellstrom@...ux.intel.com>, "Vivi, Rodrigo" <rodrigo.vivi@...el.com>,
	Yishai Hadas <yishaih@...dia.com>, Shameer Kolothum
	<skolothumtho@...dia.com>, "intel-xe@...ts.freedesktop.org"
	<intel-xe@...ts.freedesktop.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"Brost, Matthew" <matthew.brost@...el.com>, "Wajdeczko, Michal"
	<Michal.Wajdeczko@...el.com>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, Jani Nikula <jani.nikula@...ux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>, Tvrtko Ursulin
	<tursulin@...ulin.net>, David Airlie <airlied@...il.com>, Simona Vetter
	<simona@...ll.ch>, "Laguna, Lukasz" <lukasz.laguna@...el.com>, "Christoph
 Hellwig" <hch@...radead.org>
Subject: Re: [PATCH v5 28/28] vfio/xe: Add device specific vfio_pci driver
 variant for Intel graphics

On Tue, Nov 11, 2025 at 10:53:16AM +0100, Tian, Kevin wrote:
> > From: Winiarski, Michal <michal.winiarski@...el.com>
> > Sent: Tuesday, November 11, 2025 4:26 PM
> > 
> > On Tue, Nov 11, 2025 at 02:38:19AM +0100, Tian, Kevin wrote:
> > > > From: Winiarski, Michal <michal.winiarski@...el.com>
> > > > 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/20251108004754.GD1859178@ziepe.ca/
> > 
> > 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.
> 
> well it doesn't make much sense to push a new driver specific
> implementation when the core approach is preferred.

This would generally mean that accepting any new VFIO driver variant
would be blocked until core approach materializes.

Jason, can you confirm that this is indeed what you have in mind?
Just to determine how urgent the core-side changes are, and whether
there's anything we can do to help with that.

> > 
> > 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).
> 
> at least the v5 cover-letter should tell something about this plan.
> instead of leaving unaddressed opens in previous version not
> mentioned at all.
> 
> then I'll leave to Alex and Rodrigo to decide the merge plan. From
> my side I didn’t feel very risky having Xe patches and VFIO patches
> go in the mainline separately - the remaining open is mostly
> contained in vfio side. 
> 
> But now only one VFIO variant driver reviewer (me) looked at this
> series in depth. Jason gave some valuable inputs but I'm afraid
> he hasn't done a thorough review yet. Not sure we are at a point 
> with confidence that the interface between VFIO/Xe has been finalized...

I posted a subset of this series separately for inclusion in Xe tree:
https://lore.kernel.org/intel-xe/20251112132220.516975-1-michal.winiarski@intel.com/

If there are any changes requested to the interface and it impacts the
underlying implementation, we'll sort it out on Xe side.

Thanks,
-Michał