On 17-Jun-26 11:29 AM, SHANMUGAM, SRINIVASAN wrote:
AMD General
-----Original Message-----
From: Lazar, Lijo <[email protected]>
Sent: Wednesday, June 17, 2026 10:38 AM
To: SHANMUGAM, SRINIVASAN <[email protected]>;
Koenig, Christian <[email protected]>; Deucher, Alexander
<[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 5/5] drm/amdgpu: Signal GPU_RESET EVENTFD
notifications
On 12-Jun-26 11:22 AM, Srinivasan Shanmugam wrote:
Signal GPU_RESET EVENTFD subscriptions from the GPU recovery path.
The GPU recovery flow already determines when a device reset has
completed successfully. Use that point to wake up matching EVENTFD
subscribers.
It seems beneficial to send an event before and after the reset, rather than
only on
successful completion of a reset.
GPU_RESET is a device-scoped event, so no queue object is used. All
processes that subscribed to GPU_RESET on the device are notified.
My original intention was to notify userspace that GPU recovery had completed
and the device was usable again, which is why I only signaled on successful
completion.
One thing I'm trying to understand is what userspace is expected to do with a
reset-begin notification. For the other events in this series, EVENTFD is only
used as a wakeup mechanism and WAIT_EVENT provides the associated details.
Do you have a particular userspace use case in mind where observing both reset
begin and reset end would be beneficial?
This is an existing one -
https://elixir.bootlin.com/linux/v7.1/source/include/uapi/linux/kfd_ioctl.h#L536
Presently, it serves as an SMI event. Other processes may choose to halt
submissions from their side, and resume after a reset (though this is
still asynchronous).
Thanks,
Lijo
Hi @Koenig, Christian/@Deucher, Alexander: Any opinions onto this please?
Thanks!,
Srini
