linux-kernel - RE: [PATCH 26/26] vfio/xe: Add vendor-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: <BN9PR11MB52762F4BE3D250A0F40023A28CFCA@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Mon, 27 Oct 2025 07:02:17 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: "Winiarski, Michal" <michal.winiarski@...el.com>, Jason Gunthorpe
	<jgg@...pe.ca>
CC: Alex Williamson <alex.williamson@...hat.com>, "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
	<shameerali.kolothum.thodi@...wei.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>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, "Brost,
 Matthew" <matthew.brost@...el.com>, "Wajdeczko, Michal"
	<Michal.Wajdeczko@...el.com>, 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>
Subject: RE: [PATCH 26/26] vfio/xe: Add vendor-specific vfio_pci driver for
 Intel graphics

> From: Winiarski, Michal <michal.winiarski@...el.com>
> Sent: Wednesday, October 22, 2025 5:05 PM
> 
> On Tue, Oct 21, 2025 at 08:03:28PM -0300, Jason Gunthorpe wrote:
> > On Sat, Oct 11, 2025 at 09:38:47PM +0200, Michał Winiarski wrote:
> > > +	/*
> > > +	 * "STOP" handling is reused for "RUNNING_P2P", as the device
> doesn't have the capability to
> > > +	 * selectively block p2p DMA transfers.
> > > +	 * The device is not processing new workload requests when the VF is
> stopped, and both
> > > +	 * memory and MMIO communication channels are transferred to
> destination (where processing
> > > +	 * will be resumed).
> > > +	 */
> > > +	if ((cur == VFIO_DEVICE_STATE_RUNNING && new ==
> VFIO_DEVICE_STATE_STOP) ||
> > > +	    (cur == VFIO_DEVICE_STATE_RUNNING && new ==
> VFIO_DEVICE_STATE_RUNNING_P2P)) {
> > > +		ret = xe_sriov_vfio_stop(xe_vdev->pf, xe_vdev->vfid);
> >
> > This comment is not right, RUNNING_P2P means the device can still
> > receive P2P activity on it's BAR. Eg a GPU will still allow read/write
> > to its framebuffer.
> >
> > But it is not initiating any new transactions.
> 
> /*
>  * "STOP" handling is reused for "RUNNING_P2P", as the device doesn't
>  * have the capability to selectively block outgoing p2p DMA transfers.
>  * While the device is allowing BAR accesses when the VF is stopped, it
>  * is not processing any new workload requests, effectively stopping
>  * any outgoing DMA transfers (not just p2p).
>  * Both memory and MMIO communication channels with the workload
>  * scheduling firmware are transferred to destination (where processing
>  * will be resumed).
>  */
> 
> Does this work better?

it's better to articulate that not only the device allows accessing to its
MMIO regs/framebuffer but also the state of those accesses are queued/
kept and can be migrated as part of the device state later.

the last sentence is somehow related to that point, but let's make it clearer.