Re: [PATCH v1 0/6] Introduce Xe PCIe FLR

[Raag Jadav <raag.jadav@intel.com>]

On Thu, Feb 26, 2026 at 02:12:25PM -0800, Matt Roper wrote:
> On Tue, Feb 24, 2026 at 03:55:13PM +0530, Raag Jadav wrote:
> > Here's my humble attempt at introducing PCIe FLR support in xe driver.
> > This is ofcourse a half baked implementation and only limited to reloading
> > uC firmwares. This needs to be extended for a lot of different components
> > which I've skipped here for my lack of competence, so feel free to join
> > in and support them.
> > 
> > PS: This works enough to allow a single exec test run after FLR but it
> > follows with a GuC crash on subsequent runs which I'm still investigating.
> 
> Probably a dumb question since FLR while the driver is bound isn't an
> area I've considered:  if we do a PCI FLR, is there *anything* in the
> driver state that would still be relevant and useful to carry forward
> after the reset?  I believe at the hardware level vram gets wiped, all
> registers in the BAR go back to power-up defaults, etc., right?  If
> there's no state that we can meaningfully carry forward post-reset, then
> couldn't that be handled by destroying the whole xe_device (and
> releasing all of its resources), and then starting over with
> xe_pci_probe() to initialize a new one from scratch?

As an alternative yes, but that's not the userspace contract with FLR.
If user wants to reload the driver, there's a different path for it,
i.e. unbind + bind. Detailed explanation[1] from Winiarski on this.

[1] https://lore.kernel.org/intel-xe/forn7m5f2m6bwpspktrmjzvxcezcmoqyuuclu64x77uxdo5c5u@fcg3kphdb5re/

> I guess on an igpu all of our data is in smem and only the stolen memory
> gets wiped, so an FLR is a bit less destructive.  But on a dgpu I'm not
> sure how much continuation is really possible?

The expectation is to give user back a working hardware. Since VRAM is
lost, user may need to recreate memory contents, but we keep the clients
and their descriptors intact.

On a side note, this implementation is meant as a stepping stone and to
be reused for other usecases in future products.

Raag

> > Raag Jadav (6):
> >   drm/xe/uc_fw: Allow reloading firmware
> >   drm/xe/uc: Introduce FLR helpers
> >   drm/xe/irq: Introduce FLR helper
> >   drm/xe: Introduce xe_device_assert_lmem_ready()
> >   drm/xe/bo_evict: Introduce xe_bo_restore_map()
> >   drm/xe/pci: Introduce PCIe FLR
> > 
> >  drivers/gpu/drm/xe/Makefile      |   1 +
> >  drivers/gpu/drm/xe/xe_bo_evict.c |  34 +++++--
> >  drivers/gpu/drm/xe/xe_bo_evict.h |   2 +
> >  drivers/gpu/drm/xe/xe_device.c   |   4 +-
> >  drivers/gpu/drm/xe/xe_device.h   |   1 +
> >  drivers/gpu/drm/xe/xe_gsc.c      |  15 ++++
> >  drivers/gpu/drm/xe/xe_gsc.h      |   1 +
> >  drivers/gpu/drm/xe/xe_gt.c       |  10 +++
> >  drivers/gpu/drm/xe/xe_gt.h       |   2 +
> >  drivers/gpu/drm/xe/xe_guc.c      |  16 ++++
> >  drivers/gpu/drm/xe/xe_guc.h      |   1 +
> >  drivers/gpu/drm/xe/xe_huc.c      |  16 ++++
> >  drivers/gpu/drm/xe/xe_huc.h      |   1 +
> >  drivers/gpu/drm/xe/xe_irq.c      |   7 +-
> >  drivers/gpu/drm/xe/xe_irq.h      |   1 +
> >  drivers/gpu/drm/xe/xe_pci.c      |   1 +
> >  drivers/gpu/drm/xe/xe_pci.h      |   2 +
> >  drivers/gpu/drm/xe/xe_pci_err.c  | 147 +++++++++++++++++++++++++++++++
> >  drivers/gpu/drm/xe/xe_uc.c       |  24 +++++
> >  drivers/gpu/drm/xe/xe_uc.h       |   2 +
> >  drivers/gpu/drm/xe/xe_uc_fw.c    |  33 +++----
> >  drivers/gpu/drm/xe/xe_uc_fw.h    |   1 +
> >  22 files changed, 295 insertions(+), 27 deletions(-)
> >  create mode 100644 drivers/gpu/drm/xe/xe_pci_err.c
> > 
> > -- 
> > 2.43.0
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> Linux GPU Platform Enablement
> Intel Corporation