* [PATCH v4 1/2] gpu: nova-core: fix barrier usage in CPU->GSP messaging path
2026-09-01 20:59 [PATCH v4 0/2] gpu: nova: fix incorrect GSP barrier usage Gary Guo
@ 2026-09-01 20:59 ` Gary Guo
2026-09-02 7:58 ` Eliot Courtney
2026-09-01 20:59 ` [PATCH v4 2/2] gpu: nova-core: fix barrier usage in GSP->CPU " Gary Guo
2026-09-02 10:06 ` [PATCH v4 0/2] gpu: nova: fix incorrect GSP barrier usage Danilo Krummrich
2 siblings, 1 reply; 6+ messages in thread
From: Gary Guo @ 2026-09-01 20:59 UTC (permalink / raw)
To: Danilo Krummrich, Alice Ryhl, Alexandre Courbot, David Airlie,
Simona Vetter
Cc: nova-gpu, dri-devel, linux-kernel, Gary Guo
In the CPU->GSP messaging path, the code reads the read pointer from GSP,
writes the command, advances the write pointer, and then notifies the GSP.
A LOAD->STORE ordering is needed after reading the read pointer from GSP
and writing the command. Control dependency exists here which provide the
needed ordering, but it's best to avoid depending on it.
A STORE->STORE ordering is needed after the command write and before the
write pointer advance. This is currently incorrectly done after the write
pointer advance (and before GSP notification), but this can cause issue if
GSP is still processing ring buffer, as it may observe the write pointer
advance before command write. Thus move this barrier to be before the write
pointer advance. Note that barriers are not needed between write pointer
advance and GSP notification, as MMIO accessors already carries the
required barrier.
Signed-off-by: Gary Guo <gary@garyguo.net>
---
drivers/gpu/nova-core/gsp/cmdq.rs | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/nova-core/gsp/cmdq.rs b/drivers/gpu/nova-core/gsp/cmdq.rs
index 6da728201281..bfd61e678802 100644
--- a/drivers/gpu/nova-core/gsp/cmdq.rs
+++ b/drivers/gpu/nova-core/gsp/cmdq.rs
@@ -27,6 +27,11 @@
ptr,
sync::{
aref::ARef,
+ barrier::{
+ dma_mb,
+ Full,
+ Write, //
+ },
Mutex, //
},
time::Delta,
@@ -413,7 +418,12 @@ fn gsp_write_ptr(&self) -> u32 {
//
// - The returned value is within `0..MSGQ_NUM_PAGES`.
fn gsp_read_ptr(&self) -> u32 {
- MsgqRxHeader::read_ptr(io_project!(self.0, .gspq.rx)) % MSGQ_NUM_PAGES
+ let ptr = MsgqRxHeader::read_ptr(io_project!(self.0, .gspq.rx)) % MSGQ_NUM_PAGES;
+
+ // ORDERING: LOAD->STORE ordering needed to order `gsp_read_ptr` read before data write.
+ dma_mb(Full);
+
+ ptr
}
// Returns the index of the memory page the CPU can read the next message from.
@@ -447,12 +457,12 @@ fn cpu_write_ptr(&self) -> u32 {
// Informs the GSP that it can process `elem_count` new pages from the command queue.
fn advance_cpu_write_ptr(&mut self, elem_count: u32) {
+ // ORDERING: STORE->STORE ordering needed to order `cpu_write_ptr` write after data write.
+ dma_mb(Write);
+
let tx = io_project!(self.0, .cpuq.tx);
let wptr = MsgqTxHeader::write_ptr(tx).wrapping_add(elem_count) % MSGQ_NUM_PAGES;
MsgqTxHeader::set_write_ptr(tx, wptr);
-
- // Ensure all command data is visible before triggering the GSP read.
- fence(Ordering::SeqCst);
}
}
--
2.54.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v4 1/2] gpu: nova-core: fix barrier usage in CPU->GSP messaging path
2026-09-01 20:59 ` [PATCH v4 1/2] gpu: nova-core: fix barrier usage in CPU->GSP messaging path Gary Guo
@ 2026-09-02 7:58 ` Eliot Courtney
0 siblings, 0 replies; 6+ messages in thread
From: Eliot Courtney @ 2026-09-02 7:58 UTC (permalink / raw)
To: Gary Guo, Danilo Krummrich, Alice Ryhl, Alexandre Courbot,
David Airlie, Simona Vetter
Cc: nova-gpu, dri-devel, linux-kernel, dri-devel
On Wed Sep 2, 2026 at 5:59 AM JST, Gary Guo wrote:
> In the CPU->GSP messaging path, the code reads the read pointer from GSP,
> writes the command, advances the write pointer, and then notifies the GSP.
>
> A LOAD->STORE ordering is needed after reading the read pointer from GSP
> and writing the command. Control dependency exists here which provide the
> needed ordering, but it's best to avoid depending on it.
>
> A STORE->STORE ordering is needed after the command write and before the
> write pointer advance. This is currently incorrectly done after the write
> pointer advance (and before GSP notification), but this can cause issue if
> GSP is still processing ring buffer, as it may observe the write pointer
> advance before command write. Thus move this barrier to be before the write
> pointer advance. Note that barriers are not needed between write pointer
> advance and GSP notification, as MMIO accessors already carries the
> required barrier.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
> ---
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v4 2/2] gpu: nova-core: fix barrier usage in GSP->CPU messaging path
2026-09-01 20:59 [PATCH v4 0/2] gpu: nova: fix incorrect GSP barrier usage Gary Guo
2026-09-01 20:59 ` [PATCH v4 1/2] gpu: nova-core: fix barrier usage in CPU->GSP messaging path Gary Guo
@ 2026-09-01 20:59 ` Gary Guo
2026-09-02 7:58 ` Eliot Courtney
2026-09-02 10:06 ` [PATCH v4 0/2] gpu: nova: fix incorrect GSP barrier usage Danilo Krummrich
2 siblings, 1 reply; 6+ messages in thread
From: Gary Guo @ 2026-09-01 20:59 UTC (permalink / raw)
To: Danilo Krummrich, Alice Ryhl, Alexandre Courbot, David Airlie,
Simona Vetter
Cc: nova-gpu, dri-devel, linux-kernel, Gary Guo
In the GSP->CPU messaging path, the code reads the write pointer from GSP,
reads the response and advances the read pointer.
A LOAD->LOAD ordering is required after the write pointer read and the data
read. Add it as this is currently missing.
A LOAD->STORE ordering is required after the data read and the advance of
read pointer. Currently a Rust `SeqCst` barrier is used, which roughly maps
to `smp_mb(Full)`; this however does not order DMA operations (notably on
ARM, the generate barrier orders inner shareable and not outer shareable,
which is ordered by `dma_mb`). This ordering does not need to be in between
read pointer read and write, because it's for ordering between the ring
buffer data and the pointer; the RMW operation does not internally need a
barrier (nor it has to be atomic, as CPU pointers are updated by CPU only),
so move it to before the RMW sequence for clarity.
Signed-off-by: Gary Guo <gary@garyguo.net>
---
drivers/gpu/nova-core/gsp/cmdq.rs | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/nova-core/gsp/cmdq.rs b/drivers/gpu/nova-core/gsp/cmdq.rs
index bfd61e678802..14a711307654 100644
--- a/drivers/gpu/nova-core/gsp/cmdq.rs
+++ b/drivers/gpu/nova-core/gsp/cmdq.rs
@@ -2,13 +2,7 @@
mod continuation;
-use core::{
- mem,
- sync::atomic::{
- fence,
- Ordering, //
- },
-};
+use core::mem;
use kernel::{
device,
@@ -30,6 +24,7 @@
barrier::{
dma_mb,
Full,
+ Read,
Write, //
},
Mutex, //
@@ -409,7 +404,12 @@ fn allocate_command(&mut self, size: usize, timeout: Delta) -> Result<GspCommand
//
// - The returned value is within `0..MSGQ_NUM_PAGES`.
fn gsp_write_ptr(&self) -> u32 {
- MsgqTxHeader::write_ptr(io_project!(self.0, .gspq.tx)) % MSGQ_NUM_PAGES
+ let ptr = MsgqTxHeader::write_ptr(io_project!(self.0, .gspq.tx)) % MSGQ_NUM_PAGES;
+
+ // ORDERING: LOAD->LOAD ordering needed to order `gsp_write_ptr` read before data read.
+ dma_mb(Read);
+
+ ptr
}
// Returns the index of the memory page the GSP will read the next command from.
@@ -437,12 +437,11 @@ fn cpu_read_ptr(&self) -> u32 {
// Informs the GSP that it can send `elem_count` new pages into the message queue.
fn advance_cpu_read_ptr(&mut self, elem_count: u32) {
+ // ORDERING: LOAD->STORE ordering needed to order `cpu_read_ptr` write after data read.
+ dma_mb(Full);
+
let rx = io_project!(self.0, .cpuq.rx);
let rptr = MsgqRxHeader::read_ptr(rx).wrapping_add(elem_count) % MSGQ_NUM_PAGES;
-
- // Ensure read pointer is properly ordered.
- fence(Ordering::SeqCst);
-
MsgqRxHeader::set_read_ptr(rx, rptr)
}
--
2.54.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v4 2/2] gpu: nova-core: fix barrier usage in GSP->CPU messaging path
2026-09-01 20:59 ` [PATCH v4 2/2] gpu: nova-core: fix barrier usage in GSP->CPU " Gary Guo
@ 2026-09-02 7:58 ` Eliot Courtney
0 siblings, 0 replies; 6+ messages in thread
From: Eliot Courtney @ 2026-09-02 7:58 UTC (permalink / raw)
To: Gary Guo, Danilo Krummrich, Alice Ryhl, Alexandre Courbot,
David Airlie, Simona Vetter
Cc: nova-gpu, dri-devel, linux-kernel, dri-devel
On Wed Sep 2, 2026 at 5:59 AM JST, Gary Guo wrote:
> In the GSP->CPU messaging path, the code reads the write pointer from GSP,
> reads the response and advances the read pointer.
>
> A LOAD->LOAD ordering is required after the write pointer read and the data
> read. Add it as this is currently missing.
>
> A LOAD->STORE ordering is required after the data read and the advance of
> read pointer. Currently a Rust `SeqCst` barrier is used, which roughly maps
> to `smp_mb(Full)`; this however does not order DMA operations (notably on
> ARM, the generate barrier orders inner shareable and not outer shareable,
> which is ordered by `dma_mb`). This ordering does not need to be in between
> read pointer read and write, because it's for ordering between the ring
> buffer data and the pointer; the RMW operation does not internally need a
> barrier (nor it has to be atomic, as CPU pointers are updated by CPU only),
> so move it to before the RMW sequence for clarity.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
> ---
thanks!
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 0/2] gpu: nova: fix incorrect GSP barrier usage
2026-09-01 20:59 [PATCH v4 0/2] gpu: nova: fix incorrect GSP barrier usage Gary Guo
2026-09-01 20:59 ` [PATCH v4 1/2] gpu: nova-core: fix barrier usage in CPU->GSP messaging path Gary Guo
2026-09-01 20:59 ` [PATCH v4 2/2] gpu: nova-core: fix barrier usage in GSP->CPU " Gary Guo
@ 2026-09-02 10:06 ` Danilo Krummrich
2 siblings, 0 replies; 6+ messages in thread
From: Danilo Krummrich @ 2026-09-02 10:06 UTC (permalink / raw)
To: Gary Guo
Cc: Danilo Krummrich, Alice Ryhl, Alexandre Courbot, David Airlie,
Simona Vetter, nova-gpu, dri-devel, linux-kernel
On Tue, 01 Sep 2026 21:59:31 +0100, Gary Guo wrote:
> [PATCH v4 0/2] gpu: nova: fix incorrect GSP barrier usage
Applied, thanks!
Branch: drm-rust-next
Tree: https://gitlab.freedesktop.org/drm/rust/kernel.git
[1/2] gpu: nova-core: fix barrier usage in CPU->GSP messaging path
commit: 9e270c4fd863
[2/2] gpu: nova-core: fix barrier usage in GSP->CPU messaging path
commit: 6cb331644c44
The patches will appear in the next linux-next integration (typically within 24
hours on weekdays).
The patches are queued up for the upcoming merge window for the next major
kernel release.
^ permalink raw reply [flat|nested] 6+ messages in thread