RE: [RFC PATCH 0/4] Xe driver asynchronous notification mechanism

[SHANMUGAM, SRINIVASAN]

AMD General

> -----Original Message-----
> From: Koenig, Christian <Christian.Koenig@xxxxxxx>
> Sent: Monday, June 15, 2026 1:42 PM
> To: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>; intel-
> xe@xxxxxxxxxxxxxxxxxxxxx; SHANMUGAM, SRINIVASAN
> <SRINIVASAN.SHANMUGAM@xxxxxxx>
> Cc: Matthew Brost <matthew.brost@xxxxxxxxx>; Maarten Lankhorst
> <maarten.lankhorst@xxxxxxxxxxxxxxx>; Michal Mrozek <michal.mrozek@xxxxxxxxx>;
> John Falkowski <john.falkowski@xxxxxxxxx>; Rodrigo Vivi
> <rodrigo.vivi@xxxxxxxxx>; Lahtinen Joonas <joonas.lahtinen@xxxxxxxxxxxxxxx>;
> David Howells <dhowells@xxxxxxxxxx>; Christian Brauner <brauner@xxxxxxxxxx>;
> Kees Cook <kees@xxxxxxxxxx>; Davidlohr Bueso <dave@xxxxxxxxxxxx>; Dave
> Airlie <airlied@xxxxxxxxx>; Simona Vetter <simona.vetter@xxxxxxxx>; dri-
> devel@xxxxxxxxxxxxxxxxxxxxx; LMKL <linux-kernel@xxxxxxxxxxxxxxx>
> Subject: Re: [RFC PATCH 0/4] Xe driver asynchronous notification mechanism
>
> Hi Thomas, Srini,
>
> Srini is already working quite a while on something similar for amdgpu. We use
> eventfd and a device specific IOCTL instead of the watch_queue proposed here.
>
> Srini please take a look at this, it is basically the equivalent of our event notification
> approach for KFD/KGD unification. Maybe we could learn from that and/or have
> something common for both drivers.

Hi Christian, Hi Thomas,

Thank you, Christian, for pointing this out.

I took a look at the Xe series and found it very interesting to compare it with the ongoing AMDGPU EVENTFD work.

From my understanding, the Xe approach uses watch_queue for both notification and payload delivery, whereas the current AMDGPU approach uses EVENTFD as a lightweight wake-up mechanism, with WAIT_EVENT providing the details when userspace needs them.

One thing I noticed is that the event characteristics seem somewhat different. Xe appears to be dealing with relatively infrequent VM-oriented events (for example, OOM or VM restart), while AMDGPU also has queue-oriented events such as USERQ_EOP that may occur much more frequently.

I may be missing some of the bigger picture here, so I wanted to ask for your guidance on the intended direction.

Do you see watch_queue as a possible long-term common DRM notification framework that AMDGPU should eventually move towards, or is the intention mainly to compare the approaches and allow each driver to choose what best fits its event model?

I was also wondering whether it makes sense to treat these event classes differently: lightweight queue wake-up events continuing to use EVENTFD + WAIT_EVENT, while richer, lower-frequency device-level events could potentially use structured watch_queue notifications.

I would really appreciate your thoughts before we proceed further.

Thank you again for raising this and for sharing the Xe work.

Thanks,
Srini

>
> Thanks,
> Christian.