kernel/linux.git/drivers/gpu/nova-core/gsp.rs, branch linux-7.0.y

gpu: nova-core: fix stack overflow in GSP memory allocation

2026-03-10T17:29:14+00:00

The `Cmdq::new` function was allocating a `PteArray` struct on the stack and was causing a stack overflow with 8216 bytes. Modify the `PteArray` to calculate and write the Page Table Entries directly into the coherent DMA buffer one-by-one. This reduces the stack usage quite a lot. Reported-by: Gary Guo Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/509436-Nova/topic/.60Cmdq.3A.3Anew.60.20uses.20excessive.20stack.20size/near/570375549 Link: https://lore.kernel.org/rust-for-linux/CANiq72mAQxbRJZDnik3Qmd4phvFwPA01O2jwaaXRh_T+2=L-qA@mail.gmail.com/ Fixes: f38b4f105cfc ("gpu: nova-core: Create initial Gsp") Acked-by: Alexandre Courbot Signed-off-by: Tim Kovalenko Link: https://patch.msgid.link/20260309-drm-rust-next-v4-4-4ef485b19a4c@proton.me [ * Use PteArray::entry() in LogBuffer::new(), * Add TODO comment to use IoView projections once available, * Add PTE_ARRAY_SIZE constant to avoid duplication. - Danilo ] Signed-off-by: Danilo Krummrich

rust: dma: use pointer projection infra for `dma_{read,write}` macro

2026-03-07T22:06:20+00:00

Current `dma_read!`, `dma_write!` macros also use a custom `addr_of!()`-based implementation for projecting pointers, which has soundness issue as it relies on absence of `Deref` implementation on types. It also has a soundness issue where it does not protect against unaligned fields (when `#[repr(packed)]` is used) so it can generate misaligned accesses. This commit migrates them to use the general pointer projection infrastructure, which handles these cases correctly. As part of migration, the macro is updated to have an improved surface syntax. The current macro have dma_read!(a.b.c[d].e.f) to mean `a.b.c` is a DMA coherent allocation and it should project into it with `[d].e.f` and do a read, which is confusing as it makes the indexing operator integral to the macro (so it will break if you have an array of `CoherentAllocation`, for example). This also is problematic as we would like to generalize `CoherentAllocation` from just slices to arbitrary types. Make the macro expects `dma_read!(path.to.dma, .path.inside.dma)` as the canonical syntax. The index operator is no longer special and is just one type of projection (in additional to field projection). Similarly, make `dma_write!(path.to.dma, .path.inside.dma, value)` become the canonical syntax for writing. Another issue of the current macro is that it is always fallible. This makes sense with existing design of `CoherentAllocation`, but once we support fixed size arrays with `CoherentAllocation`, it is desirable to have the ability to perform infallible indexing as well, e.g. doing a `[0]` index of `[Foo; 2]` is okay and can be checked at build-time, so forcing falliblity is non-ideal. To capture this, the macro is changed to use `[idx]` as infallible projection and `[idx]?` as fallible index projection (those syntax are part of the general projection infra). A benefit of this is that while individual indexing operation may fail, the overall read/write operation is not fallible. Fixes: ad2907b4e308 ("rust: add dma coherent allocator abstraction") Reviewed-by: Benno Lossin Signed-off-by: Gary Guo Link: https://patch.msgid.link/20260302164239.284084-4-gary@kernel.org [ Capitalize safety comments; slightly improve wording in doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich

gpu: nova-core: align LibosMemoryRegionInitArgument size to page size

2026-01-24T01:48:59+00:00

On Turing and GA100 (i.e. the versions that use Libos v2), GSP-RM insists that the 'size' parameter of the LibosMemoryRegionInitArgument struct be aligned to 4KB. The logging buffers are already aligned to that size, so only the GSP_ARGUMENTS_CACHED struct needs to be adjusted. Make that adjustment by adding padding to the end of the struct. Signed-off-by: Timur Tabi Reviewed-by: Gary Guo Acked-by: Danilo Krummrich Link: https://patch.msgid.link/20260122222848.2555890-12-ttabi@nvidia.com [acourbot@nvidia.com: GspArgumentsAligned -> GspArgumentsPadded] Signed-off-by: Alexandre Courbot

gpu: nova-core: gsp: move appropriate code into pin initializer

2025-12-29T16:54:32+00:00

Relocate the code that technically fits in the pin initializer into the initializer itself. While, thanks to pin_init_scope(), it is also possible to keep it as is, moving appropriate code into the initializer has the advantage that it structures the dependencies of fields naturally. For instance, intermediate data that is only needed for a single field goes into the initializer block of this field, making it obvious that it is not needed by anything else. On the other hand, intermediate data that is needed for multiple fields to initialize remains above the initializer, naturally indicating that it is needed my multiple fields. Reviewed-by: Joel Fernandes Link: https://patch.msgid.link/20251218155239.25243-5-dakr@kernel.org Signed-off-by: Danilo Krummrich

gpu: nova-core: gsp: get rid of redundant Result in Gsp::new()

2025-12-29T16:54:31+00:00

In Gsp::new(), utilize pin_init_scope() to get rid of the Result in the returned Result> which is unnecessarily redundant. Reviewed-by: Joel Fernandes Link: https://patch.msgid.link/20251218155239.25243-4-dakr@kernel.org Signed-off-by: Danilo Krummrich

gpu: nova-core: Implement the GSP sequencer

2025-11-15T12:05:50+00:00

Implement the GSP sequencer which culminates in INIT_DONE message being received from the GSP indicating that the GSP has successfully booted. This is just initial sequencer support, the actual commands will be added in the next patches. Signed-off-by: Joel Fernandes [acourbot@nvidia.com: move GspSequencerInfo definition before its impl blocks and rename it to GspSequence, adapt imports in sequencer.rs to new formatting rules, remove `timeout` argument to harmonize with other commands.] Signed-off-by: Alexandre Courbot Message-ID: <20251114195552.739371-8-joelagnelf@nvidia.com>

gpu: nova-core: gsp: Add SetSystemInfo command

2025-11-14T11:25:57+00:00

Add support for sending the SetSystemInfo command, which provides required hardware information to the GSP and is critical to its initialization. Signed-off-by: Alistair Popple Signed-off-by: Alexandre Courbot Message-ID: <20251110-gsp_boot-v9-11-8ae4058e3c0e@nvidia.com>

gpu: nova-core: gsp: Create rmargs

2025-11-14T11:25:57+00:00

Initialise the GSP resource manager arguments (rmargs) which provides initialisation parameters to the GSP firmware during boot. The rmargs structure contains arguments to configure the GSP message/command queue location. These are mapped for coherent DMA and added to the libos data structure for access when booting GSP. Signed-off-by: Alistair Popple Co-developed-by: Alexandre Courbot Signed-off-by: Alexandre Courbot Message-ID: <20251110-gsp_boot-v9-10-8ae4058e3c0e@nvidia.com>

gpu: nova-core: gsp: Add GSP command queue bindings and handling

2025-11-14T11:25:57+00:00

This commit introduces core infrastructure for handling GSP command and message queues in the nova-core driver. The command queue system enables bidirectional communication between the host driver and GSP firmware through a remote message passing interface. The interface is based on passing serialised data structures over a ring buffer with separate transmit and receive queues. Commands are sent by writing to the CPU transmit queue and waiting for completion via the receive queue. To ensure safety mutable or immutable (depending on whether it is a send or receive operation) references are taken on the command queue when allocating the message to write/read to. This ensures message memory remains valid and the command queue can't be mutated whilst an operation is in progress. Currently this is only used by the probe() routine and therefore can only used by a single thread of execution. Locking to enable safe access from multiple threads will be introduced in a future series when that becomes necessary. Signed-off-by: Alistair Popple Co-developed-by: Alexandre Courbot Signed-off-by: Alexandre Courbot Message-ID: <20251110-gsp_boot-v9-9-8ae4058e3c0e@nvidia.com>

gpu: nova-core: Create initial Gsp

2025-11-14T11:25:56+00:00

The GSP requires several areas of memory to operate. Each of these have their own simple embedded page tables. Set these up and map them for DMA to/from GSP using CoherentAllocation's. Return the DMA handle describing where each of these regions are for future use when booting GSP. Signed-off-by: Alistair Popple Co-developed-by: Alexandre Courbot Signed-off-by: Alexandre Courbot Message-ID: <20251110-gsp_boot-v9-4-8ae4058e3c0e@nvidia.com>