| 91645a52 | 05-Aug-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
rust: dma: rename dma_handle to dma_address
The `dma_handle` naming is inherited from the C API, but what this
really describes is the device DMA address; everything named
`dma_handle` is actually a
rust: dma: rename dma_handle to dma_address
The `dma_handle` naming is inherited from the C API, but what this
really describes is the device DMA address; everything named
`dma_handle` is actually a `dma_addr_t`.
This naming introduces some confusion on the Rust API side, as handles
are supposed to be opaque tokens, yet we were doing address computation
on values returned by `dma_handle`.
Rename `dma_handle` to `dma_address` while nova-core is still its only
user.
Suggested-by: John Hubbard <jhubbard@nvidia.com>
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/all/DK75LUA4NLGI.3P29AIZQE20V2@kernel.org/
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Link: https://patch.msgid.link/20260805-falcon-dma-projections-v2-2-4cc9f3f13ee9@nvidia.com
[ Rebase and fix up build failures due to newly introduced dma_handle()
calls. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| ad515782 | 31-Jul-2026 |
Timur Tabi <ttabi@nvidia.com> |
gpu: nova-core: transition booter to TLV images
Switch the booter firmware loader from the legacy binary format to the
TLV format. This change requires the new TLV versions of the r570.144
firmware
gpu: nova-core: transition booter to TLV images
Switch the booter firmware loader from the legacy binary format to the
TLV format. This change requires the new TLV versions of the r570.144
firmware images.
The new TLV format has all of the metadata needed by Nova encoded as
separate tags, eliminating the need to parse legacy firmware headers
such as HsHeaderV2 and HsSignatureParams. All of the structs and
code for parsing those headers is therefore deleted.
Signed-off-by: Timur Tabi <ttabi@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://patch.msgid.link/20260731201017.2580713-5-ttabi@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 528aef3a | 04-Aug-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
gpu: nova-core: pass WPR metadata ownership to FmcBootArgs
`FmcBootArgs` logically owns this, so pass ownership to it instead of
storing a reference.
Signed-off-by: Eliot Courtney <ecourtney@nvidia
gpu: nova-core: pass WPR metadata ownership to FmcBootArgs
`FmcBootArgs` logically owns this, so pass ownership to it instead of
storing a reference.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-5-ac858b6a1935@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 6e46097f | 04-Aug-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
gpu: nova-core: split FbLayout into FSP and non-FSP versions
`FbLayout` is currently used for both pre and post FSP architectures. It
contains ranges for each region of framebuffer, but on post FSP
gpu: nova-core: split FbLayout into FSP and non-FSP versions
`FbLayout` is currently used for both pre and post FSP architectures. It
contains ranges for each region of framebuffer, but on post FSP
architectures, only the size is actually used. The region locations are
decided by ACR, which runs as part of the GSP-FMC, not by the driver.
The driver only provides the sizes. So, for post FSP architectures
`FbLayout` contains essentially guesses for the offsets. Instead, make
separate types so that we only store the information that's actually
needed, rather than keeping around offsets that may not be correct.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-4-ac858b6a1935@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 9c96c8c2 | 03-Jul-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
gpu: nova-core: gsp: ensure LibOS DMA allocation lives long enough
Currently, `GspSequencer` stores a raw DMA handle. Instead, store a
reference to `Coherent` to statically ensure that the allocatio
gpu: nova-core: gsp: ensure LibOS DMA allocation lives long enough
Currently, `GspSequencer` stores a raw DMA handle. Instead, store a
reference to `Coherent` to statically ensure that the allocation lives
long enough.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Alistair Popple <apopple@nvidia.com>
Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-4-8e3d8bc32bb9@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| d76956f7 | 03-Jul-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
gpu: nova-core: gsp: ensure lifetime for FMC boot DMA allocations
Currently, `FmcBootArgs` takes DMA handles directly, rather than
references to the `Coherent` for them. This is error prone, so inst
gpu: nova-core: gsp: ensure lifetime for FMC boot DMA allocations
Currently, `FmcBootArgs` takes DMA handles directly, rather than
references to the `Coherent` for them. This is error prone, so instead
store lifetime'd references to the `Coherent` allocation.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-3-8e3d8bc32bb9@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| ce2d97f7 | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: store Fsp instance in Gpu
The `Fsp` instance was only used in the Hopper+ boot path, and
consequently built locally (and immediately dropped) in it.
This worked well as a temporary
gpu: nova-core: store Fsp instance in Gpu
The `Fsp` instance was only used in the Hopper+ boot path, and
consequently built locally (and immediately dropped) in it.
This worked well as a temporary measure, but the FSP is a GPU
sub-device, so its lifetime should match the GPU rather than a single
boot invocation.
It will also be needed in other parts of the driver, for instance vGPU.
Thus, create the `Fsp` instance in the `Gpu` constructor and store it
there, passing it to the GSP boot as a mutable reference using
`GspBootContext`. This makes the `Fsp` available even after the GSP is
booted.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-13-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 320608e5 | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: separate context and GPU lifetimes in GspBootContext
`Falcon` instances retain references tied to the lifetime of the bound
GPU. `GspBootContext` currently uses that same lifeti
gpu: nova-core: gsp: separate context and GPU lifetimes in GspBootContext
`Falcon` instances retain references tied to the lifetime of the bound
GPU. `GspBootContext` currently uses that same lifetime for its own
borrows of the `Falcon` instances and other references.
But these lifetimes are independent: the references captured by a
`Falcon` remain valid for the GPU lifetime, while the context only
borrows the `Falcon` for the duration of a boot or unload operation.
This distinction is hidden for shared references by covariance, but
cannot be ignored anymore if the context carries mutable references to
GPU subdevices, as will happen for the `Fsp` and the `Falcon`s.
Thus, give `GspBootContext` separate lifetimes for its subdevice borrows
and the GPU resources captured by those subdevices, and update its users
accordingly.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-12-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 43f890d8 | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: pass GspBootContext mutably
We want to move the `Fsp` instance into `Gpu`, which will require
passing it as a mutable reference in `GspBootContext`, since
`Fsp::boot_fmc` is a m
gpu: nova-core: gsp: pass GspBootContext mutably
We want to move the `Fsp` instance into `Gpu`, which will require
passing it as a mutable reference in `GspBootContext`, since
`Fsp::boot_fmc` is a mutable method. In order to use the mutable
references it contains, `GspBootContext` must also be mutable.
We will also follow up by making some methods of the `Falcon`s mutable,
which also requires passing them as mutable references.
Thus, make the `GspBootContext` passed to `Gsp::boot` and `Gsp::unload`
mutable, and pass mutable references to it to the GSP boot HAL methods.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-11-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| bb2d0073 | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: make use of FWSEC bootloader a property of the TU102 HAL
By being in the TU102 HAL, we already know that the GSP boot method is
the SEC2 Booter, so the only variable is whether
gpu: nova-core: gsp: make use of FWSEC bootloader a property of the TU102 HAL
By being in the TU102 HAL, we already know that the GSP boot method is
the SEC2 Booter, so the only variable is whether the FWSEC bootloader is
used or not. Since `Chipset` also includes the variants that boot FSP,
querying it for that information introduces a potential code path (a
chipset that boots via FSP) that the current code doesn't handle.
Turn the use of the FWSEC bootloader into a property of the `Tu102` HAL,
and give GA102+ chipsets their own instance with that property set to
`false`. This removes the invalid code path and the only use of
`Chipset` is now to load the correct firmware files.
This also removes some uses of the `Chipset::needs_fwsec_bootloader`
method and prepares the ground for removing it.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-8-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 7567e62b | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: turn FWSEC execution into HAL method
Turn the `run_fwsec_frts` function into a method of `Tu102`. A following
patch will turn the "use FWSEC bootloader" property into a flag of
gpu: nova-core: gsp: turn FWSEC execution into HAL method
Turn the `run_fwsec_frts` function into a method of `Tu102`. A following
patch will turn the "use FWSEC bootloader" property into a flag of the
TU102 HAL itself, and making this a method will allow the code to access
it instead of querying `Chipset`.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-7-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 436f3c4a | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: fold TU102 unload bundle construction into HAL method
The construction of the unload bundle is currently a bit convoluted and
could be done in one function instead of two.
Addi
gpu: nova-core: gsp: fold TU102 unload bundle construction into HAL method
The construction of the unload bundle is currently a bit convoluted and
could be done in one function instead of two.
Additionally, turn that function into a method of `Tu102`. A following
patch will turn the "use FWSEC bootloader" property into a flag of the
TU102 HAL itself, and making this a method will allow the code to access
it instead of querying `Chipset`.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-6-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 92faa16f | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: centralize missing unload bundle warnings
The warning emitted when the unload bundle cannot be constructed is
valid regardless of the boot method, but it was local to `Tu102`. M
gpu: nova-core: gsp: centralize missing unload bundle warnings
The warning emitted when the unload bundle cannot be constructed is
valid regardless of the boot method, but it was local to `Tu102`. Move
it to `Gsp::boot` so it applies to all boot methods.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-5-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 3099edaa | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: pass GspBootContext to unload methods
`GspBootContext` contains the resources required to boot the GSP. As it
turns out, this is also the context required for unloading it.
Ref
gpu: nova-core: gsp: pass GspBootContext to unload methods
`GspBootContext` contains the resources required to boot the GSP. As it
turns out, this is also the context required for unloading it.
Reflect that fact by replacing the arguments of `Gsp::unload` and
`UnloadBundle::run` with the `GspBootContext`. This symmetry between
`Gsp::boot` and `Gsp::unload` will also be convenient when we want to
make these methods generic over the boot context corresponding to the
boot method used.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-4-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| ebf164be | 09-Jul-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: replace BootUnloadGuard with local handlers
When adding the GSP unload capability, we introduced `BootUnloadGuard`
to automatically call `Gsp::unload` whenever an error occurred
gpu: nova-core: gsp: replace BootUnloadGuard with local handlers
When adding the GSP unload capability, we introduced `BootUnloadGuard`
to automatically call `Gsp::unload` whenever an error occurred during
the boot process, in order to try to reset the GSP to a valid state.
This approach is not well-suited to the errors that may occur in HALs:
by definition, an error occurring in the HAL means that the GSP is not
booted; yet the first thing that `Gsp::unload` does is queue a shutdown
message to the GSP, which will inevitably result in a timeout when done
from a HAL.
Furthermore, `BootUnloadGuard` is problematic because it holds
additional references to the boot context, notably the `Falcon`s. These
extra references stand in the way of making some of the `Falcon`'s
methods mutable, since those methods would require exclusive access. As
this behavior is only needed in one place, introducing dedicated types
for it is distracting and unnecessary.
Thus, remove `BootUnloadGuard` and adopt a two-level error handling
strategy:
- HALs are free to handle their errors as they see fit (most likely, by
running their unload bundle if it is ready by the time of the error),
- `Gsp::boot` uses a `ScopeGuard` that runs `Gsp::unload`, since the
GSP should be up and running by the time `GspHal::boot` has returned.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260709-nova-bootcontext-v6-3-520cbf8b9b50@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 44396428 | 15-Jun-2026 |
Eliot Courtney <ecourtney@nvidia.com> |
gpu: nova-core: fsp: move FMC firmware loading into wait_secure_boot
`FspFirmware` is constructed and immediately passed into `Fsp`. It makes
sense for `Fsp` to ask to load its firmware, so move it
gpu: nova-core: fsp: move FMC firmware loading into wait_secure_boot
`FspFirmware` is constructed and immediately passed into `Fsp`. It makes
sense for `Fsp` to ask to load its firmware, so move it there.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260615-blackwell-fixes-v1-6-f2853e49ff7d@nvidia.com
[acourbot: fix minor merge conflict.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| e6558738 | 04-Jun-2026 |
Zhi Wang <zhiw@nvidia.com> |
gpu: nova-core: consolidate GSP boot parameters into GspBootContext
The GspHal trait methods boot() and post_boot() accept a long list of
individual parameters (dev, bar, chipset, gsp_falcon, sec2_f
gpu: nova-core: consolidate GSP boot parameters into GspBootContext
The GspHal trait methods boot() and post_boot() accept a long list of
individual parameters (dev, bar, chipset, gsp_falcon, sec2_falcon) that
are threaded through the entire GSP boot call chain. This makes the
signatures unwieldy and difficult to extend as new boot-time context
(e.g. vGPU state) is introduced.
Introduce a GspBootContext struct that bundles the common boot
parameters into a single object, and refactor the GspHal trait to accept
&GspBootContext instead of individual arguments. The struct also exposes
a dev() helper with proper lifetime annotation so that HAL
implementations can extract the device reference without reborrowing
constraints.
Update both TU102 and GH100 HAL implementations to extract their
required parameters from the context struct, and simplify the call sites
in Gsp::boot() accordingly.
Signed-off-by: Zhi Wang <zhiw@nvidia.com>
Link: https://patch.msgid.link/20260604114339.1565660-7-zhiw@nvidia.com
[acourbot: pass `GspBootContext` by value to `Gsp::boot`.]
[acourbot: deconstruct `GspBootContext` in `Gsp::boot` to simplify diff.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 9eaff547 | 31-May-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: tu102: keep unloading if FWSEC-SB fails
On Turing and Ampere, resetting the GSP involves running two firmware
images: FWSEC-SB and Booter Unloader. They are independent from one
gpu: nova-core: gsp: tu102: keep unloading if FWSEC-SB fails
On Turing and Ampere, resetting the GSP involves running two firmware
images: FWSEC-SB and Booter Unloader. They are independent from one
another, and we should do whatever is possible to restore the GSP's
unloaded state even if a failure occurs along the way.
Thus, keep going and run Booter Unloader even if the execution of
FWSEC-SB failed.
Fixes: adb99ce3cc78 ("gpu: nova-core: run Booter Unloader and FWSEC-SB upon unbinding")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260529-nova-unload-v7-0-678f39209e00%40nvidia.com?part=3
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260531-nova-unload-fix-v1-1-c8dcdc769b53@nvidia.com
[acourbot: log Booter Unloader errors.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|
| 723bd79c | 03-Jun-2026 |
Alexandre Courbot <acourbot@nvidia.com> |
gpu: nova-core: gsp: enable FSP boot path
Now that all the elements are in place, enable the FSP boot path so
Hopper and Blackwell can boot.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link:
gpu: nova-core: gsp: enable FSP boot path
Now that all the elements are in place, enable the FSP boot path so
Hopper and Blackwell can boot.
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260603-b4-blackwell-v13-9-d9f3a06939e0@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
show more ...
|