AMD's NPU3 driver drops the userspace doorbell
David Zhang's 21-patch series moves NPU3 command submission from userspace doorbell mapping into kernel mode, adding fence management and full suspend/resume support.

The AIE4 NPU3, the neural processing unit embedded in AMD's Ryzen AI 300 and Ryzen AI 300 PRO series SoCs, has been dispatching its commands through a userspace doorbell mapping. Every command crossed a userspace-to-kernel boundary before the hardware acknowledged it. That path worked, but it added a context switch to every transaction, and under sustained inference workloads the cumulative cost becomes visible. David Zhang, an AMD engineer, has been working to eliminate that overhead. His 21-patch series, posted to the Linux kernel mailing list on 26 September 2026, moves command submission into the kernel proper and makes it the default execution path for NPU3 hardware.
The kernel-mode command submission, which Zhang abbreviates KMQ, replaces the userspace doorbell as the primary dispatch route. The patches add fence management to track completion of in-flight commands, BO reservation locking to prevent concurrent access to buffer objects, and queue lifecycle handling to manage the creation and teardown of submission queues. New clock and frequency queries let the driver read device telemetry directly from kernel space rather than round-tripping through a userspace ioctl. The series also introduces NPU3 classic device support, a device class the previous driver did not recognize, and establishes the kernel-mode path as the default rather than an optional alternative.
Power management receives a full rework. The patches implement system suspend and resume across Physical Functions, Virtual Functions, and Classic devices, each of which previously lacked a coherent power state transition in the Linux driver. SR-IOV power management dependency linking ties the PF and VF power states together so that a virtual function cannot enter a low-power state the physical function has not authorized. Userspace runtime compatibility stubs keep existing applications functional during the transition, preventing a hard break for workloads that still reference the old doorbell interface. The combination of suspend, resume, and runtime PM in a single patch set is what distinguishes this series from incremental driver fixes.
No latency figures appear in the patch series. No throughput comparison against the old userspace doorbell path is offered. No target kernel version is named, and the source does not state whether the 21 patches have been reviewed or merged into any mainline tree. The Ryzen AI 300 SoCs are already in the market, which means the gap between hardware availability and driver maturity is the open question. What is not measured here is the cost of the context switch that KMQ removes, and whether the kernel-mode path introduces its own scheduling overhead under sustained load. The next step is a merge window, and the question is whether the power management patches land before or after the command submission changes.
The shift from userspace doorbell to kernel-mode submission eliminates a per-command context switch, but the patch series offers no latency or throughput data to quantify the gain. Power management coverage across PF, VF, and Classic devices is the more structural contribution, as it enables SR-IOV workloads to suspend cleanly.
21 patches posted to LKML · NPU3 in Ryzen AI 300 / 300 PRO SoCs · KMQ replaces userspace doorbell mapping · SR-IOV PM dependency linking across PF/VF
After Phoronix. We did not report this. The pictures, if any, are theirs.


