| Age | Commit message (Collapse) | Author |
|---|
|
A GPU interrupt can be lost in the MSI or MSI-X allocation, in the GIN
tree's enables, or in the rearm, and every one of those failures looks
the same: no interrupt arrives, and no register or log line says which
one broke.
Add a probe-time self-test, built under NOVA_CORE_SELFTESTS, that
latches the CPU doorbell vector through the GIN software trigger and
waits for a registered handler to service it. One delivery would pass
with a broken rearm, because the first message-signaled interrupt
arrives whether or not the driver rearms, so the test triggers twice and
waits for the first handler to finish before the second trigger. It runs
after GFW boot and before GSP boot, on a quiesced tree, and fails probe
unless both deliveries arrive, each finds only the doorbell pending, and
the leaf ends clear.
The doorbell has the same vector on every supported GPU, so the test
names it without asking GSP-RM. It allocates the PCI vectors for the
doorbell's subtree and releases them before returning, so under MSI-X
the delivery also exercises that subtree's table entry.
Assisted-by: LLM
Co-developed-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260930034148.590687-9-jhubbard@nvidia.com
[acourbot: move relevant bits of previous patch into this one.]
[acourbot: remove reference to self-test section of documentation.]
[acourbot: replace completions with atomic polling code.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Extend GpuMm with the remaining two memory-management components:
- Buddy allocator for VRAM allocation.
- TLB manager for translation buffer operations.
PRAMIN was added in an earlier commit; this completes the centralized
ownership model with accessor methods for each component.
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
[ecourtney: rebase GpuMm for borrowed BAR0, pin Tlb, write regs directly]
[ecourtney: size the buddy from the first usable FB region, drop dev_info]
[ecourtney: update for the VramAddress raw API and typed register base]
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260909-mmrebase-v1-2-8dd5d4225d2e@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
The existing assert! and assert_eq! macros cause a panic. For self tests
in nova-core, it's inconvenient to cause a panic since these need to be
run on actual hardware. Instead, define similar macros that log an error
then return an Err.
Also add the NOVA_CORE_SELFTESTS Kconfig option that gates the driver
self-tests.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20260827-pramin-split-v3-9-24b24d7afc52@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
Update nova/Makefile and nova-core/Makefile so that nova-drm.ko and
nova-core.ko are produced, matching the module names set in patch 1.
Update drm::DriverInfo with the correct driver name and vendor
description. Fix Kconfig help text for both drivers and the debugfs
directory name in nova-core to match the new module names.
Closes: https://github.com/Rust-for-Linux/linux/issues/1228
Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com>
Link: https://patch.msgid.link/20260507185012.1527139-3-yphbchou0911@gmail.com
[ Change commit subject to "gpu: nova: Use module names consistently";
slightly adjust commit message. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The driver already assumes little endian in a lot of locations. For
example, all the code that reads RPCs out of the command queue just
directly interprets the bytes.
Make this explicit in Kconfig.
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Link: https://patch.msgid.link/20260407-fix-kconfig-v2-1-6b4fb06c690c@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Reorder the select statements in NOVA_CORE Kconfig to be in
alphabetical order.
Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Link: https://patch.msgid.link/20260224225323.3312204-3-joelagnelf@nvidia.com
[acourbot@nvidia.com: fix conflict due to patch reordering.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
RUST_FW_LOADER_ABSTRACTIONS was depended on by NOVA_CORE, but NOVA_CORE
is selected by DRM_NOVA. This creates a situation where, if DRM_NOVA is
selected, NOVA_CORE gets enabled but not RUST_FW_LOADER_ABSTRACTIONS,
which results in a build error.
Since the firmware loader is an implementation detail of the driver, it
should be enabled along with it, so change the "depends on" to a
"select".
Fixes: 54e6baf123fd ("gpu: nova-core: add initial driver stub")
Closes: https://lore.kernel.org/oe-kbuild-all/202512061721.rxKGnt5q-lkp@intel.com/
Tested-by: Alyssa Ross <hi@alyssa.is>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20251106-b4-select-rust-fw-v3-2-771172257755@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
|
|
If built on architectures with CONFIG_ARCH_DMA_ADDR_T_64BIT=y nova-core
produces that following build failures:
error[E0308]: mismatched types
--> drivers/gpu/nova-core/fb.rs:49:59
|
49 | hal::fb_hal(chipset).write_sysmem_flush_page(bar, page.dma_handle())?;
| ----------------------- ^^^^^^^^^^^^^^^^^ expected `u64`, found `u32`
| |
| arguments to this method are incorrect
|
note: method defined here
--> drivers/gpu/nova-core/fb/hal.rs:19:8
|
19 | fn write_sysmem_flush_page(&self, bar: &Bar0, addr: u64) -> Result;
| ^^^^^^^^^^^^^^^^^^^^^^^
help: you can convert a `u32` to a `u64`
|
49 | hal::fb_hal(chipset).write_sysmem_flush_page(bar, page.dma_handle().into())?;
| +++++++
error[E0308]: mismatched types
--> drivers/gpu/nova-core/fb.rs:65:47
|
65 | if hal.read_sysmem_flush_page(bar) == self.page.dma_handle() {
| ------------------------------- ^^^^^^^^^^^^^^^^^^^^^^ expected `u64`, found `u32`
| |
| expected because this is `u64`
|
help: you can convert a `u32` to a `u64`
|
65 | if hal.read_sysmem_flush_page(bar) == self.page.dma_handle().into() {
| +++++++
error: this arithmetic operation will overflow
--> drivers/gpu/nova-core/falcon.rs:469:23
|
469 | .set_base((dma_start >> 40) as u16)
| ^^^^^^^^^^^^^^^^^ attempt to shift right by `40_i32`, which would overflow
|
= note: `#[deny(arithmetic_overflow)]` on by default
This is due to the code making assumptions on the width of dma_addr_t to
be 64 bit.
While this could technically be handled, it is rather painful to deal
with, as the following example illustrates:
pub(super) fn read_sysmem_flush_page_ga100(bar: &Bar0) -> DmaAddress {
let addr = u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08())
<< FLUSH_SYSMEM_ADDR_SHIFT
| u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40())
<< FLUSH_SYSMEM_ADDR_SHIFT_HI;
addr.try_into().unwrap_or_else(|_| {
kernel::warn_on!(true);
0
})
}
At the same time there's not much value for nova-core to support 32-bit,
given that the supported GPU architectures are Turing and later, hence
depend on CONFIG_64BIT.
Cc: John Hubbard <jhubbard@nvidia.com>
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://lore.kernel.org/lkml/20250828160247.37492-1-ojeda@kernel.org/
Fixes: 6554ad65b589 ("gpu: nova-core: register sysmem flush page")
Fixes: 69f5cd67ce41 ("gpu: nova-core: add falcon register definitions and base code")
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Link: https://lore.kernel.org/r/20250828223954.351348-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
CONFIG_AUXILIARY_BUS cannot be enabled explicitly, and unless we select
it we have no way to include it (and thus to enable NOVA_CORE) unless
another driver happens to do it for us.
Fixes: e041d81a0377 ("gpu: nova-core: register auxiliary device for nova-drm")
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250515-aux_bus-v2-2-47c70f96ae9b@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Register an auxiliary device for nova-drm.
For now always use zero for the auxiliary device's ID; we don't use it
yet anyways. However, once it lands, we should switch to XArray.
Acked-by: Dave Airlie <airlied@redhat.com>
Link: https://lore.kernel.org/r/20250424160452.8070-2-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Add the initial nova-core driver stub.
nova-core is intended to serve as a common base for nova-drm (the
corresponding DRM driver) and the vGPU manager VFIO driver, serving as a
hard- and firmware abstraction layer for GSP-based NVIDIA GPUs.
The Nova project, including nova-core and nova-drm, in the long term,
is intended to serve as the successor of Nouveau for all GSP-based GPUs.
The motivation for both, starting a successor project for Nouveau and
doing so using the Rust programming language, is documented in detail
through a previous post on the mailing list [1], an LWN article [2] and a
talk from LPC '24.
In order to avoid the chicken and egg problem to require a user to
upstream Rust abstractions, but at the same time require the Rust
abstractions to implement the driver, nova-core kicks off as a driver
stub and is subsequently developed upstream.
Link: https://lore.kernel.org/dri-devel/Zfsj0_tb-0-tNrJy@cassiopeiae/T/#u [1]
Link: https://lwn.net/Articles/990736/ [2]
Link: https://youtu.be/3Igmx28B3BQ?si=sBdSEer4tAPKGpOs [3]
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250306222336.23482-5-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
