On 6/17/26 08:22, Lazar, Lijo wrote: > 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).
We have rejected exactly that approach in the past because it makes the whole handling quite unreliable. This has been proposed before and was then later removed as buggy. As far as I can see notification before the reset doesn't have much value since you can't block the reset. Regards, Christian. > > Thanks, > Lijo > >> >> Hi @Koenig, Christian/@Deucher, Alexander: Any opinions onto this please? >> >> Thanks!, >> Srini >
