From: Alexandre Courbot <acourbot@nvidia.com>
To: "Danilo Krummrich" <dakr@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>
Cc: John Hubbard <jhubbard@nvidia.com>,
Alistair Popple <apopple@nvidia.com>,
Joel Fernandes <joelagnelf@nvidia.com>,
Timur Tabi <ttabi@nvidia.com>, Edwin Peer <epeer@nvidia.com>,
Eliot Courtney <ecourtney@nvidia.com>,
nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
rust-for-linux@vger.kernel.org,
Alexandre Courbot <acourbot@nvidia.com>
Subject: [PATCH 0/7] gpu: nova-core: run unload sequence upon unbinding
Date: Tue, 16 Dec 2025 14:13:26 +0900 [thread overview]
Message-ID: <20251216-nova-unload-v1-0-6a5d823be19d@nvidia.com> (raw)
Currently the GSP is left running and the WPR2 memory region untouched
as the driver is unbound. This is obviously not idea for at least two
reasons:
- Probing requires setting up the WPR2 region, which cannot be done if
there is already one in place. Thus the current requirement to reset
the GPU (using e.g. `echo 1 >/sys/bus/pci/devices/.../reset`) before
the driver can be probed again after removal.
- The running GSP may still attempt to access shared memory regions,
which the kernel might recycle.
This patchset does the necessary to leave the GPU in a clean state after
unbind.
First are a few preparatory patches:
- Running the unload sequence requires mutable access to the driver
data, but the current device unbind method only passes a non-mutable
reference to it. Since the driver data is destroyed after the call to
`unbind`, we can just give ownership back to the driver at this stage
to solve this issue.
The need for mutable access is likely to go away in Nova after we
support concurrency on the command queue, but for now we need it and
it looks like a sensible design direction anyway.
- A `warn_on_err` macro is introduced to call `warn_on` if the passed
`Result` is an error. This simplifies the unbind sequence's code as we
need to proceed to the next step even if the previous one failed.
- A fix (?) to the automatically-generated pin-projected structures,
suppressing the warnings when using them partially.
With these in place, the rest of the patchset is relatively trivial. We
change the signatures of methods related to unbinding to work with
mutable pinned driver data, then implement the two steps of the GPU
unbind sequence: asking the GSP to shut down, and removing the WPR2
protected memory area.
This series sits on top of the following:
- Nova fixes for this cycle [1].
- Nova misc improvements [2].
- Transmute on ZSTs [3].
A tree with all the required patches is available in [4].
[1] https://lore.kernel.org/all/20251216-nova-fixes-v3-0-c7469a71f7c4@nvidia.com/
[2] https://lore.kernel.org/all/20251216-nova-misc-v2-0-dc7b42586c04@nvidia.com/
[3] https://lore.kernel.org/all/20251215-transmute_unit-v4-0-477d71ec7c23@nvidia.com/
[4] https://github.com/Gnurou/linux/tree/b4/nova-unload
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Alexandre Courbot (7):
rust: pci: pass driver data by value to `unbind`
rust: add warn_on_err macro
gpu: nova-core: use warn_on_err macro
[RFC] rust: pin-init: allow `dead_code` on projection structure
gpu: nova-nova: use pin-init projections
gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command GSP upon unloading
gpu: nova-core: run Booter Unloader and FWSEC-SB upon unbinding
drivers/gpu/nova-core/driver.rs | 4 +-
drivers/gpu/nova-core/firmware/booter.rs | 1 -
drivers/gpu/nova-core/firmware/fwsec.rs | 1 -
drivers/gpu/nova-core/gpu.rs | 25 ++++++--
drivers/gpu/nova-core/gsp/boot.rs | 77 +++++++++++++++++++++++
drivers/gpu/nova-core/gsp/commands.rs | 42 +++++++++++++
drivers/gpu/nova-core/gsp/fw.rs | 4 ++
drivers/gpu/nova-core/gsp/fw/commands.rs | 27 ++++++++
drivers/gpu/nova-core/gsp/fw/r570_144/bindings.rs | 8 +++
drivers/gpu/nova-core/regs.rs | 5 ++
rust/kernel/bug.rs | 10 +++
rust/kernel/pci.rs | 4 +-
rust/pin-init/src/macros.rs | 1 +
samples/rust/rust_driver_pci.rs | 2 +-
14 files changed, 198 insertions(+), 13 deletions(-)
---
base-commit: 8d4031f6a53fe47449b91f30cd7aa5b439558874
change-id: 20251216-nova-unload-4029b3b76950
Best regards,
--
Alexandre Courbot <acourbot@nvidia.com>
next reply other threads:[~2025-12-16 5:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-16 5:13 Alexandre Courbot [this message]
2025-12-16 5:13 ` [PATCH 1/7] rust: pci: pass driver data by value to `unbind` Alexandre Courbot
2025-12-16 12:14 ` Danilo Krummrich
2025-12-16 14:38 ` Alexandre Courbot
2025-12-16 5:13 ` [PATCH 2/7] rust: add warn_on_err macro Alexandre Courbot
2025-12-16 5:13 ` [PATCH 3/7] gpu: nova-core: use " Alexandre Courbot
2025-12-16 5:13 ` [PATCH RFC 4/7] rust: pin-init: allow `dead_code` on projection structure Alexandre Courbot
2025-12-16 6:12 ` Benno Lossin
2025-12-16 5:13 ` [PATCH 5/7] gpu: nova-nova: use pin-init projections Alexandre Courbot
2025-12-16 5:13 ` [PATCH 6/7] gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command GSP upon unloading Alexandre Courbot
2025-12-16 15:39 ` Joel Fernandes
2025-12-18 13:27 ` Alexandre Courbot
2025-12-18 20:52 ` Joel Fernandes
2025-12-19 3:26 ` Alexandre Courbot
2025-12-19 6:42 ` Joel Fernandes
2025-12-18 22:33 ` Timur Tabi
2025-12-18 22:44 ` Joel Fernandes
2025-12-18 23:34 ` Timur Tabi
2025-12-19 1:46 ` Joel Fernandes
2025-12-19 1:48 ` Joel Fernandes
2025-12-19 3:39 ` Alexandre Courbot
2025-12-20 21:30 ` Timur Tabi
2026-01-14 14:02 ` Alexandre Courbot
2025-12-16 5:13 ` [PATCH 7/7] gpu: nova-core: run Booter Unloader and FWSEC-SB upon unbinding Alexandre Courbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251216-nova-unload-v1-0-6a5d823be19d@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ecourtney@nvidia.com \
--cc=epeer@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox