All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "Winiarski, Michal" <michal.winiarski@intel.com>,
	"Alex Williamson" <alex@shazbot.org>,
	"De Marchi, Lucas" <lucas.demarchi@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
	"Yishai Hadas" <yishaih@nvidia.com>,
	"Shameer Kolothum" <skolothumtho@nvidia.com>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Brost, Matthew" <matthew.brost@intel.com>,
	"Wajdeczko, Michal" <Michal.Wajdeczko@intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Tvrtko Ursulin" <tursulin@ursulin.net>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Laguna, Lukasz" <lukasz.laguna@intel.com>,
	"Christoph Hellwig" <hch@infradead.org>,
	"Cabiddu, Giovanni" <giovanni.cabiddu@intel.com>,
	"Brett Creeley" <brett.creeley@amd.com>
Subject: Re: [PATCH v4 28/28] vfio/xe: Add device specific vfio_pci driver variant for Intel graphics
Date: Fri, 7 Nov 2025 20:47:54 -0400	[thread overview]
Message-ID: <20251108004754.GD1859178@ziepe.ca> (raw)
In-Reply-To: <BN9PR11MB52768763573DF22AB978C8228CC3A@BN9PR11MB5276.namprd11.prod.outlook.com>

On Fri, Nov 07, 2025 at 03:10:33AM +0000, Tian, Kevin wrote:
> > To me, it looks like something generic, that will have impact on any
> > device specific driver variant.
> > What am I missing?
> > 
> > I wonder if drivers that don't implement the deferred reset trick were
> > ever executed with lockdep enabled.
> > 
> 
> @Jason, @Yishai, @Shameer, @Giovanni, @Brett:
> 
> Sounds it's a right thing to pull back the deferred reset trick into
> every driver. anything overlooked?

It does seem like we should probably do something in the core code to
help this and remove the duplication.

I guess it makes sense the read/write lock would become entangled too.

Jason

  reply	other threads:[~2025-11-08  0:47 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-05 15:09 [PATCH v4 00/28] vfio/xe: Add driver variant for Xe VF migration Michał Winiarski
2025-11-05 15:09 ` [PATCH v4 01/28] drm/xe/pf: Remove GuC version check for migration support Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 02/28] drm/xe: Move migration support to device-level struct Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 03/28] drm/xe/pf: Convert control state to bitmap Michał Winiarski
2025-11-05 18:51   ` Michal Wajdeczko
2025-11-05 15:10 ` [PATCH v4 04/28] drm/xe/pf: Add save/restore control state stubs and connect to debugfs Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 05/28] drm/xe/pf: Add data structures and handlers for migration rings Michał Winiarski
2025-11-05 20:17   ` Michal Wajdeczko
2025-11-06 11:24     ` Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 06/28] drm/xe/pf: Add helpers for migration data packet allocation / free Michał Winiarski
2025-11-05 21:12   ` Michal Wajdeczko
2025-11-06 11:30     ` Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 07/28] drm/xe/pf: Add support for encap/decap of bitstream to/from packet Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 08/28] drm/xe/pf: Add minimalistic migration descriptor Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 09/28] drm/xe/pf: Expose VF migration data size over debugfs Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 10/28] drm/xe: Add sa/guc_buf_cache sync interface Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 11/28] drm/xe: Allow the caller to pass guc_buf_cache size Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 12/28] drm/xe/pf: Increase PF GuC Buffer Cache size and use it for VF migration Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 13/28] drm/xe/pf: Remove GuC migration data save/restore from GT debugfs Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 14/28] drm/xe/pf: Don't save GuC VF migration data on pause Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 15/28] drm/xe/pf: Switch VF migration GuC save/restore to struct migration data Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 16/28] drm/xe/pf: Handle GuC migration data as part of PF control Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 17/28] drm/xe/pf: Add helpers for VF GGTT migration data handling Michał Winiarski
2025-11-05 21:45   ` Michal Wajdeczko
2025-11-06 11:31     ` Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 18/28] drm/xe/pf: Handle GGTT migration data as part of PF control Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 19/28] drm/xe/pf: Handle MMIO " Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 20/28] drm/xe/pf: Add helper to retrieve VF's LMEM object Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 21/28] drm/xe/migrate: Add function to copy of VRAM data in chunks Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 22/28] drm/xe/pf: Handle VRAM migration data as part of PF control Michał Winiarski
2025-11-08  4:31   ` Matthew Brost
2025-11-05 15:10 ` [PATCH v4 23/28] drm/xe/pf: Add wait helper for VF FLR Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 24/28] drm/xe/pf: Enable SR-IOV VF migration Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 25/28] drm/xe/pci: Introduce a helper to allow VF access to PF xe_device Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 26/28] drm/xe/pf: Export helpers for VFIO Michał Winiarski
2025-11-05 15:10 ` [PATCH v4 27/28] drm/intel/bmg: Allow device ID usage with single-argument macros Michał Winiarski
2025-11-07 14:51   ` Lucas De Marchi
2025-11-05 15:10 ` [PATCH v4 28/28] vfio/xe: Add device specific vfio_pci driver variant for Intel graphics Michał Winiarski
2025-11-06  8:20   ` Tian, Kevin
2025-11-06 10:55     ` Winiarski, Michal
2025-11-07  3:10       ` Tian, Kevin
2025-11-08  0:47         ` Jason Gunthorpe [this message]
2025-11-08  1:05           ` Tian, Kevin
2025-11-08  1:11             ` Jason Gunthorpe
2025-11-05 18:07 ` ✗ CI.checkpatch: warning for vfio/xe: Add driver variant for Xe VF migration (rev4) Patchwork
2025-11-05 18:08 ` ✓ CI.KUnit: success " Patchwork
2025-11-05 19:30 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-11-06  3:30 ` ✓ Xe.CI.Full: success " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251108004754.GD1859178@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=Michal.Wajdeczko@intel.com \
    --cc=airlied@gmail.com \
    --cc=alex@shazbot.org \
    --cc=brett.creeley@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=giovanni.cabiddu@intel.com \
    --cc=hch@infradead.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=lukasz.laguna@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=michal.winiarski@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=skolothumtho@nvidia.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tursulin@ursulin.net \
    --cc=yishaih@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.