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

From: SHANMUGAM, SRINIVASAN

Date: Tue Jun 16 2026 - 07:23:30 EST


AMD General

> -----Original Message-----
> From: SHANMUGAM, SRINIVASAN
> Sent: Monday, June 15, 2026 2:37 PM
> To: Koenig, Christian <Christian.Koenig@xxxxxxx>; Thomas Hellström
> <thomas.hellstrom@xxxxxxxxxxxxxxx>; intel-xe@xxxxxxxxxxxxxxxxxxxxx
> 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
>
>
>
> > -----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
>

Hi Christian,

Sharing the AMDGPU patch series for reference:

EVENTFD series: https://patchwork.freedesktop.org/series/164618/
WAIT_EVENT series: https://patchwork.freedesktop.org/series/164813/#rev7

Xe seems to be solving a similar notification problem, so these may be useful for comparison.

Thanks,
Srini


> >
> > Thanks,
> > Christian.