Re: [PATCH] drm/xe/pm: do not warn about missing runtime PM protection after hot-unplug

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

On Thu, Aug 06, 2026 at 11:39:50AM +0530, Gote, Nitin R wrote:
> > From: Jadav, Raag <raag.jadav@intel.com>
> > On Thu, Jul 30, 2026 at 05:35:26PM +0530, Gote, Nitin R wrote:
> > > > From: Jadav, Raag <raag.jadav@intel.com> On Thu, Jul 30, 2026 at
> > > > 11:06:36AM +0530, Nitin Gote wrote:
> > > > > After hot-unplug, device_del() disables runtime PM. A deferred fd
> > > > > close can still run later during process exit and destroy
> > > > > remaining exec queues, which may call xe_pm_runtime_get_noresume().
> > > >
> > > > This sounds like could cause many other side effects. Why not make
> > > > sure the exec queues are taken care of as part of hot-unplug path?
> > > >
> > >
> > > Here In igt@core_hotunplug@hotreplug-with-load and
> > > igt@core_hotunplug@hotunplug-rescan-with-load subtests, the workload
> > > keeps the DRM fd open while the device is pci hot-unplugged. Later, fd
> > > close reaches
> > > guc_exec_queue_destroy() -> guc_exec_queue_add_msg() ->
> > > xe_pm_runtime_get_noresume(), after pci_remove/device_del() path has
> > already called pm_runtime_disable() during pci hot-unplug.
> > >
> > > So the WARN is a false-positive for the already-unplugged device case.
> > > I will update the commit message to make this scope clearer.
> > 
> > I guess my question was, is it safe have the exec queues lying around until fd
> > close? Wouldn't it be more appropriate to have them cleaned up as part of hot-
> > unplug itself?
> > 
> 
> The exec queues are owned by user space through open DRM fds, so they're freed when the fd is closed, not forced at unplug. 
> drm_dev_unplug() marks the device unplugged but keeps the drm_device alive while fds are open, 
> we can't destroy a queue while it's still referenced by an open fd.
> 
> The hardware side is already cleaned up at unplug; guc_fini_hw() runs in the remove path and sanitizes GuC.
> So by the time the fd closes, only the software state of the queue is left, and that's what gets freed here.
> And when it does, the cleanup path checks xe_uc_fw_is_running(), sees GuC is gone, and takes the software only teardown.

Makes sense. Although runtime PM is for when you need to interact with the
hardware, so in my understanding we shouldn't be at this point for software
only teardown, but I'll leave it to you all.

Raag