The GSP-RM log buffers are exposed through debugfs, but the entries are
owned by the Gpu that probe() builds, and the buffers themselves are DMA
allocations that cannot outlive the device. They are therefore gone as
soon as the GPU is unbound, and in particular as soon as probe() fails -
which is the case todo.rst singled out ("even after failure to probe the
driver"), and the one where a GSP log is worth having.

Patch 1 adds CONFIG_NOVA_CORE_KEEP_GSP_LOGS: when the log buffers are
dropped, whatever the GSP wrote is copied into memory owned by the
module and exposed under a "retained" directory until the module is
unloaded. Patch 2 drops the now completed task from todo.rst.

nouveau has the same feature behind its keep_gsp_logging module
parameter. It recreates the entries under the name of the GPU that just
went away, which collides with that GPU coming back; the "retained"
directory here avoids that.

Tested on a GB203 (RTX 5080), which the driver probes successfully:

  - after an unbind, retained/<BDF>/{loginit,logintr,logrm} hold the
    contents the live entries had;
  - with a failure injected after the GSP has booted, probe() fails and
    the logs of that attempt are still readable;
  - binding the GPU again does not disturb the copies, and unbinding it
    a second time replaces them;
  - the copies are released on module unload, with nothing left behind;
  - with the option off, the entries disappear on unbind as before.

Built and checked with CLIPPY=1 and rustfmtcheck for both settings of
the new option.

The testing was done on top of e6c2c6265521 ("rust: firmware: add
request_into_buf()"), that is, before the TLV firmware series, because
the nvidia/*/gsp/*.tlv images are not in linux-firmware yet and the
driver therefore cannot load firmware at the current tip. The series
applies and builds unchanged on top of drm-rust-next.

Vladislav Zaharov (2):
  gpu: nova-core: gsp: retain the GSP-RM log buffers after unbind
  Documentation: nova: remove completed GSP log buffer task

 Documentation/gpu/nova/core/todo.rst |  12 ---
 drivers/gpu/nova-core/Kconfig        |  18 ++++
 drivers/gpu/nova-core/gsp.rs         | 146 +++++++++++++++++++++++++++
 drivers/gpu/nova-core/nova_core.rs   |  19 ++++
 4 files changed, 183 insertions(+), 12 deletions(-)

-- 
2.55.0

On Wed Aug 12, 2026 at 1:37 PM CEST, Vladislav Zaharov wrote:
> The testing was done on top of e6c2c6265521 ("rust: firmware: add
> request_into_buf()"), that is, before the TLV firmware series, because
> the nvidia/*/gsp/*.tlv images are not in linux-firmware yet and the
> driver therefore cannot load firmware at the current tip. The series
> applies and builds unchanged on top of drm-rust-next.

Unless you already know and decided against it, a firmware archive containing
the compatible firmware for the current tip can be found in [1].

[1] https://github.com/ttabi/linux-firmware-nova

On Wed Aug 12, 2026 at 5:54 PM CEST, Danilo Krummrich wrote:
> Unless you already know and decided against it, a firmware archive containing
> the compatible firmware for the current tip can be found in [1].
>
> [1] https://github.com/ttabi/linux-firmware-nova

I did not - I only found that repository after sending this series, so the
older base was ignorance rather than a decision. Thanks.

I will install those images and re-run the same checks on top of the current
tip over the next few days: unbind, a probe made to fail after the GSP is up,
a second retain for the same device, and module unload. I will report the
result here.

Beyond this series: I have a GB203 (RTX 5080) here running nova-core, so if
any pending nova-core work would benefit from being exercised on Blackwell, I
am happy to test it and send Tested-by.

One last thing: English is not my first language, and I use an LLM partly as a
translator. If you would rather I did not, I can write these mails through a
plain translator instead, though some of the meaning will be lost that way.

Thanks,
Vladislav

On Thu Aug 13, 2026, Danilo Krummrich wrote:
> I think those should use VVec.
> Let's move all the LogBuffer code into gsp/logbuffer.rs to keep gsp.rs clean.
> I think we can avoid this additional unsafe if we just create the retained dir
> right away in module_init().
> dev_dbg!() should be good enough.

All four make sense, thanks - v2 will have them. Creating the retained
directory in module_init() also removes the only reason retain() had to look
at DEBUGFS_ROOT, so the unsafe block goes away with it.

On Thu Aug 13, 2026, John Hubbard wrote:
> I'd *much* rather use a kernel parameter: keep_gsp_logs, instead of
> requiring a rebuild of the kernel.

Agreed, and it makes the patch smaller: with a module parameter the cfg gating
disappears and the code is simply always built. I used a Kconfig because of the
"the only Kconfig needed is for retaining the GSP log buffers after driver
unbind" remark in the earlier thread, which I took literally instead of asking.

That one needs a decision, though. The Rust module parameter abstraction has no
bool: rust/kernel/module_param.rs only instantiates param ops for i8..u64,
isize and usize, and rust/macros/module.rs panics on anything else. Nor is it
quite a one-liner to add, since bare bool parameters rely on
KERNEL_PARAM_OPS_FL_NOARG, which make_param_ops! cannot currently express.

I am happy to write that prerequisite patch, but it would pull this series into
rust/kernel review. So unless bool support is already in flight somewhere I
have not found, I propose v2 uses u8 for now and moves to bool once it exists.
Say the word if you would rather have it done properly first.

The re-test on top of the current tip is still owed; I will run it before v2
and report the result in its cover letter.

Thanks,
Vladislav

On 8/12/26 10:50 PM, Vladislav Zaharov wrote:
> On Thu Aug 13, 2026, Danilo Krummrich wrote:
>> I'd *much* rather use a kernel parameter: keep_gsp_logs, instead of
>> requiring a rebuild of the kernel.
> 
> Agreed, and it makes the patch smaller: with a module parameter the cfg gating
> disappears and the code is simply always built. I used a Kconfig because of the
> "the only Kconfig needed is for retaining the GSP log buffers after driver
> unbind" remark in the earlier thread, which I took literally instead of asking.
> 
> That one needs a decision, though. The Rust module parameter abstraction has no
> bool: rust/kernel/module_param.rs only instantiates param ops for i8..u64,

Yes, this seems perfectly acceptable, given that we don't have bool support yet:

   keep_gsp_logs=[0|1]


thanks,
-- 
John Hubbard

On Thu Aug 13, 2026 at 8:37 PM BST, John Hubbard wrote:
> On 8/12/26 10:50 PM, Vladislav Zaharov wrote:
>> On Thu Aug 13, 2026, Danilo Krummrich wrote:
>>> I'd *much* rather use a kernel parameter: keep_gsp_logs, instead of
>>> requiring a rebuild of the kernel.
>> 
>> Agreed, and it makes the patch smaller: with a module parameter the cfg gating
>> disappears and the code is simply always built. I used a Kconfig because of the
>> "the only Kconfig needed is for retaining the GSP log buffers after driver
>> unbind" remark in the earlier thread, which I took literally instead of asking.
>> 
>> That one needs a decision, though. The Rust module parameter abstraction has no
>> bool: rust/kernel/module_param.rs only instantiates param ops for i8..u64,
>
> Yes, this seems perfectly acceptable, given that we don't have bool support yet:
>
>    keep_gsp_logs=[0|1]
>
>
> thanks,

We have bool support.

https://rust.docs.kernel.org/next/kernel/module_param/trait.ModuleParam.html#impl-ModuleParam-for-bool

Best,
Gary