[PATCH v4 0/7] gpu: nova: Export parameters from nova-core to nova-drm

[PATCH v4 0/7] gpu: nova: Export parameters from nova-core to nova-drm

[Alistair Popple]

This patch series adds some basic GPU properties via a new GPU info ioctl. It
builds on top of the "drm: Higher-Ranked Lifetime private data" series[1] to
correctly manage lifetimes of registration data shared between DRM, auxbus and
nova-core. It's also based on top of "ForLt/CovariantForLt split, auxiliary
closure API and DevresLt"[2] although the functionality of that series isn't
actually required.

A tree with this series applied on top of all pre-requisites is available at
[3].

Properties are exported via a new NovaCoreApi type which implements methods to
read data from the GPU. This has been implemented in a separate module to make
the public API implementations obvious and to keep them in one place. Auxiliary
bus drivers can obtain a handle to this type using NovaCoreApi::of().

This handle can then be stored as part of the DRM registration data and used to
interact with the GPU via the nova-core driver.

Changes since v3:

 - Use an ioctl to return all parameters rather than multiple key/value queries

Changes since v2:

 - Addressed review Danilo and Alex
 - Minor renames to better align with HW based on internal feedback

Changes since v1:

 - Address review comments from Danilo
 - Add an API call to read VRAM PCI BAR size using nova-core
 
[1] - https://lore.kernel.org/rust-for-linux/20260628145406.2107056-1-dakr@kernel.org/
[2] - https://lore.kernel.org/driver-core/20260626183630.2585057-1-dakr@kernel.org/
[3] - https://github.com/apopple-nvidia/linux/tree/nova-drm

Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Alice Ryhl <aliceryhl@google.com>
Cc: David Airlie <airlied@gmail.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Benno Lossin <lossin@kernel.org>
Cc: Gary Guo <gary@garyguo.net>
Cc: Eliot Courtney <ecourtney@nvidia.com>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: linux-kernel@vger.kernel.org
Cc: nova-gpu@lists.linux.dev
Cc: dri-devel@lists.freedesktop.org
Cc: rust-for-linux@vger.kernel.org

Alistair Popple (7):
  gpu: nova-core: Add public driver API to nova-core
  drm: nova: Add DRM registration data
  drm: nova: Add chipid enum to nova-drm UAPI
  drm: nova: Add a GPU info ioctl
  drm: nova: Add usable VRAM size to GPU info ioctl
  drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter
  drm: nova: Expose a render node

 drivers/gpu/drm/nova/driver.rs        | 18 ++++++-
 drivers/gpu/drm/nova/file.rs          | 40 +++++++++-----
 drivers/gpu/nova-core/api.rs          | 49 +++++++++++++++++
 drivers/gpu/nova-core/driver.rs       | 44 +++++++++++----
 drivers/gpu/nova-core/gpu.rs          | 78 ++++++++++++++-------------
 drivers/gpu/nova-core/gsp/commands.rs |  8 +++
 drivers/gpu/nova-core/gsp/hal.rs      |  2 +-
 drivers/gpu/nova-core/nova_core.rs    |  1 +
 include/uapi/drm/nova_drm.h           | 71 ++++++++++++++++++++++++
 9 files changed, 247 insertions(+), 64 deletions(-)
 create mode 100644 drivers/gpu/nova-core/api.rs

-- 
2.54.0

[PATCH v4 1/7] gpu: nova-core: Add public driver API to nova-core

[Alistair Popple]

Nova core will be used to export core functionality to other drivers
which will bind to it via auxiliary bus devices. Add a NovaCoreApi type
which drivers can use to call nova-core methods.

Auxiliary bus drivers can obtain a handle to call nova-core methods on
a particular GPU using NovaCoreApi::of(). This takes a reference to a
bound auxiliary bus device and returns a handle to NovaCoreApi.

Signed-off-by: Alistair Popple <apopple@nvidia.com>

---

Changes since v2:

 - Add accidentally dropped TODO comment

Changes since v1:

 - Rework unsafe pin-init to make safety comments clearer, suggested
   by Danilo.
 - s/allow(dead_code)/expect(unused)/
---
 drivers/gpu/nova-core/api.rs       | 29 ++++++++++++++++++++
 drivers/gpu/nova-core/driver.rs    | 44 ++++++++++++++++++++++--------
 drivers/gpu/nova-core/gsp/hal.rs   |  2 +-
 drivers/gpu/nova-core/nova_core.rs |  1 +
 4 files changed, 64 insertions(+), 12 deletions(-)
 create mode 100644 drivers/gpu/nova-core/api.rs

diff --git a/drivers/gpu/nova-core/api.rs b/drivers/gpu/nova-core/api.rs
new file mode 100644
index 000000000000..610cfc01111e
--- /dev/null
+++ b/drivers/gpu/nova-core/api.rs
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Nova-core auxbus data. Contains all the methods used by the auxbus drivers
+//! to interact with nova-core.
+
+use core::pin::Pin;
+
+use kernel::{
+    auxiliary,
+    device::Bound,
+    prelude::*,
+    types::CovariantForLt, //
+};
+
+use crate::gpu::Gpu;
+
+/// API handle for the auxiliary bus child drivers to interact with nova-core.
+pub struct NovaCoreApi<'bound> {
+    #[expect(unused)]
+    pub(crate) gpu: Pin<&'bound Gpu<'bound>>,
+}
+
+impl NovaCoreApi<'_> {
+    /// Obtain a [`NovaCoreApi`] handle from an auxiliary device registered
+    /// by nova-core.
+    pub fn of(adev: &auxiliary::Device<Bound>) -> Result<Pin<&NovaCoreApi<'_>>> {
+        adev.registration_data::<CovariantForLt!(NovaCoreApi<'_>)>()
+    }
+}
diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
index 48380ac15f68..435aa917d3e7 100644
--- a/drivers/gpu/nova-core/driver.rs
+++ b/drivers/gpu/nova-core/driver.rs
@@ -18,6 +18,7 @@
     types::CovariantForLt,
 };
 
+use crate::api::NovaCoreApi;
 use crate::gpu::Gpu;
 
 /// Counter for generating unique auxiliary device IDs.
@@ -25,11 +26,14 @@
 
 #[pin_data]
 pub(crate) struct NovaCore<'bound> {
+    // Fields are dropped in declaration order: unregister the auxiliary
+    // device before dropping `gpu`, and drop `gpu` before `bar` because `Gpu`
+    // borrows `bar`.
+    #[allow(clippy::type_complexity)]
+    _reg: auxiliary::Registration<'bound, CovariantForLt!(NovaCoreApi<'_>)>,
     #[pin]
     pub(crate) gpu: Gpu<'bound>,
     bar: pci::Bar<'bound, BAR0_SIZE>,
-    #[allow(clippy::type_complexity)]
-    _reg: auxiliary::Registration<'bound, CovariantForLt!(())>,
 }
 
 pub(crate) struct NovaCoreDriver;
@@ -86,15 +90,33 @@ fn probe<'bound>(
                 // (`try_pin_init!()` initializes fields in declaration order), lives at a pinned
                 // stable address, and is dropped after `gpu` (struct field drop order).
                 gpu <- Gpu::new(pdev, unsafe { &*core::ptr::from_ref(bar) }),
-                _reg: auxiliary::Registration::new(
-                    pdev.as_ref(),
-                    c"nova-drm",
-                    // TODO[XARR]: Use XArray or perhaps IDA for proper ID allocation/recycling. For
-                    // now, use a simple atomic counter that never recycles IDs.
-                    AUXILIARY_ID_COUNTER.fetch_add(1, Relaxed),
-                    crate::MODULE_NAME,
-                    (),
-                )?,
+
+                _reg: {
+                    // TODO: Use `&gpu` self-referential pin-init syntax once available.
+                    //
+                    // SAFETY: `gpu` is initialized before this expression is evaluated
+                    // (`try_pin_init!()` initializes fields in declaration order), lives at
+                    // a pinned stable address, and is dropped after `_reg` (struct field
+                    // drop order).
+                    let gpu = unsafe {
+                        Pin::new_unchecked(&*core::ptr::from_ref(gpu.as_ref().get_ref()))
+                    };
+
+                    // SAFETY: `NovaCore` is dropped when the device is unbound;
+                    // i.e. `mem::forget()` is never called on it.
+                    unsafe {
+                        auxiliary::Registration::new_with_lt(
+                            pdev.as_ref(),
+                            c"nova-drm",
+                            // TODO[XARR]: Use XArray or perhaps IDA for proper ID
+                            // allocation/recycling. For now, use a simple atomic counter that
+                            // never recycles IDs.
+                            AUXILIARY_ID_COUNTER.fetch_add(1, Relaxed),
+                            crate::MODULE_NAME,
+                            NovaCoreApi { gpu },
+                        )?
+                    }
+                },
             }))
         })
     }
diff --git a/drivers/gpu/nova-core/gsp/hal.rs b/drivers/gpu/nova-core/gsp/hal.rs
index 34b4bb82a999..b59bcaf2042e 100644
--- a/drivers/gpu/nova-core/gsp/hal.rs
+++ b/drivers/gpu/nova-core/gsp/hal.rs
@@ -29,7 +29,7 @@
 /// The GSP unload code might run in a situation where we cannot load firmware dynamically (e.g.
 /// because we are in shutdown and the file system is not accessible anymore). Thus, the firmware
 /// required for unloading is prepared at load time, and stored here until it needs to be run.
-pub(super) trait UnloadBundle: Send {
+pub(super) trait UnloadBundle: Send + Sync {
     /// Performs the steps required to properly reset the GSP after it has been stopped.
     fn run(&self, ctx: &mut GspBootContext<'_, '_>) -> Result;
 }
diff --git a/drivers/gpu/nova-core/nova_core.rs b/drivers/gpu/nova-core/nova_core.rs
index a61406ba5c0b..9463ae038e81 100644
--- a/drivers/gpu/nova-core/nova_core.rs
+++ b/drivers/gpu/nova-core/nova_core.rs
@@ -10,6 +10,7 @@
     InPlaceModule, //
 };
 
+pub mod api;
 mod driver;
 mod falcon;
 mod fb;
-- 
2.54.0

[PATCH v4 2/7] drm: nova: Add DRM registration data

[Alistair Popple]

Currently the nova-drm stub driver doesn't really interact with a real
device, so it doesn't have any registration data and has no way to call
into nova-core.

To allow for this add a DrmRegData type which will hold a reference to
the NovaCoreApi associated with the auxbus device.

Signed-off-by: Alistair Popple <apopple@nvidia.com>
Suggested-by: Danilo Krummrich <dakr@kernel.org>

---

Changes from v2:

 - Add newline in crate import

Changes from v1:

 - Drop unrelated device::Bound removal.
 - Switch exisiting import to vertical style.
 - s/allow(dead_code)/expect(unused)/
---
 drivers/gpu/drm/nova/driver.rs | 17 +++++++++++++++--
 drivers/gpu/drm/nova/file.rs   | 12 ++++++++----
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nova/driver.rs b/drivers/gpu/drm/nova/driver.rs
index 739690bc2db5..632137d1c6d7 100644
--- a/drivers/gpu/drm/nova/driver.rs
+++ b/drivers/gpu/drm/nova/driver.rs
@@ -1,5 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
+use core::pin::Pin;
+
 use kernel::{
     auxiliary,
     device::{
@@ -18,6 +20,8 @@
 use crate::file::File;
 use crate::gem::NovaObject;
 
+use nova_core::api::NovaCoreApi;
+
 pub(crate) struct NovaDriver;
 
 pub(crate) struct Nova<'bound> {
@@ -26,6 +30,12 @@ pub(crate) struct Nova<'bound> {
     _reg: drm::Registration<'bound, NovaDriver>,
 }
 
+/// DRM registration data, accessible from ioctl handlers via the registration guard.
+pub(crate) struct DrmRegData<'bound> {
+    #[expect(unused)]
+    pub(crate) api: Pin<&'bound NovaCoreApi<'bound>>,
+}
+
 /// Convienence type alias for the DRM device type for this driver
 pub(crate) type NovaDevice<Ctx = drm::Normal> = drm::Device<NovaDriver, Ctx>;
 
@@ -60,9 +70,12 @@ fn probe<'bound>(
         _info: &'bound Self::IdInfo,
     ) -> impl PinInit<Self::Data<'bound>, Error> + 'bound {
         let drm = drm::UnregisteredDevice::<Self>::new(adev, Ok(()))?;
+        let reg_data = DrmRegData {
+            api: NovaCoreApi::of(adev)?,
+        };
         // SAFETY: `reg` is stored in `Nova` and dropped when the driver is unbound; it is
         // never forgotten.
-        let reg = unsafe { drm::Registration::new(adev.as_ref(), drm, (), 0)? };
+        let reg = unsafe { drm::Registration::new(adev.as_ref(), drm, reg_data, 0)? };
 
         Ok(Nova {
             drm: reg.device().into(),
@@ -74,7 +87,7 @@ fn probe<'bound>(
 #[vtable]
 impl drm::Driver for NovaDriver {
     type Data = ();
-    type RegistrationData<'a> = ();
+    type RegistrationData<'a> = DrmRegData<'a>;
     type File = File;
     type Object = gem::Object<NovaObject>;
     type ParentDevice<Ctx: DeviceContext> = auxiliary::Device<Ctx>;
diff --git a/drivers/gpu/drm/nova/file.rs b/drivers/gpu/drm/nova/file.rs
index 298c02bacb4b..1156df51c533 100644
--- a/drivers/gpu/drm/nova/file.rs
+++ b/drivers/gpu/drm/nova/file.rs
@@ -1,6 +1,10 @@
 // SPDX-License-Identifier: GPL-2.0
 
-use crate::driver::{NovaDevice, NovaDriver};
+use crate::driver::{
+    DrmRegData,
+    NovaDevice,
+    NovaDriver, //
+};
 use crate::gem::NovaObject;
 use kernel::{
     alloc::flags::*,
@@ -30,7 +34,7 @@ impl File {
     /// IOCTL: get_param: Query GPU / driver metadata.
     pub(crate) fn get_param(
         dev: &NovaDevice<Registered>,
-        _reg_data: &(),
+        _reg_data: &DrmRegData<'_>,
         getparam: &mut uapi::drm_nova_getparam,
         _file: &drm::File<File>,
     ) -> Result<u32> {
@@ -50,7 +54,7 @@ pub(crate) fn get_param(
     /// IOCTL: gem_create: Create a new DRM GEM object.
     pub(crate) fn gem_create(
         dev: &NovaDevice<Registered>,
-        _reg_data: &(),
+        _reg_data: &DrmRegData<'_>,
         req: &mut uapi::drm_nova_gem_create,
         file: &drm::File<File>,
     ) -> Result<u32> {
@@ -64,7 +68,7 @@ pub(crate) fn gem_create(
     /// IOCTL: gem_info: Query GEM metadata.
     pub(crate) fn gem_info(
         _dev: &NovaDevice<Registered>,
-        _reg_data: &(),
+        _reg_data: &DrmRegData<'_>,
         req: &mut uapi::drm_nova_gem_info,
         file: &drm::File<File>,
     ) -> Result<u32> {
-- 
2.54.0

[PATCH v4 3/7] drm: nova: Add chipid enum to nova-drm UAPI

[Alistair Popple]

The chipid contains the GPU architecture and implementation and needs
to be exposed to user-space. This adds a public enum to the userspace
headers for each chip ID. Nova-core can then use this enum to define
its chipsets.

This does create a coupling between nova-drm and nova-core whereby
nova-core depends on the values defined by the user-space API for
nova-drm. However this is entirely appropriate as nova-core must be
bound by the UAPI headers as the enum values are read by nova-core and
passed through to user-space.

Note that nova-core currently refers to the chipid as a chipset. This
isn't ideal given that chipid is the preferred and more accurate term
and is what should be exposed via the uAPI. Therefore a future patch
series will be posted that aligns nova-core internals to using chipid
rather than chipset.

Signed-off-by: Alistair Popple <apopple@nvidia.com>

---

Changes since v3:

 - New for v4, split out from "drm: nova: Add GETPARAM parameter to read
   the GPU chipset"
---
 drivers/gpu/nova-core/gpu.rs | 64 +++++++++++++++++++-----------------
 include/uapi/drm/nova_drm.h  | 38 +++++++++++++++++++++
 2 files changed, 72 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 442c0979f9c6..738a590e753b 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -10,7 +10,8 @@
     num::Bounded,
     pci,
     prelude::*,
-    sizes::SizeConstants, //
+    sizes::SizeConstants,
+    uapi, //
 };
 
 use crate::{
@@ -35,12 +36,13 @@
 mod hal;
 
 macro_rules! define_chipset {
-    ({ $($variant:ident = $value:expr),* $(,)* }) =>
+    ({ $($variant:ident),* $(,)* }) =>
     {
+        ::kernel::macros::paste!(
         /// Enum representation of the GPU chipset.
         #[derive(fmt::Debug, Copy, Clone, PartialOrd, Ord, PartialEq, Eq)]
         pub(crate) enum Chipset {
-            $($variant = $value),*,
+            $($variant = uapi::[<drm_nova_chipid_NOVA_DRM_CHIPID_ $variant:upper>] as isize),*,
         }
 
         impl Chipset {
@@ -48,7 +50,6 @@ impl Chipset {
                 $( Chipset::$variant, )*
             ];
 
-            ::kernel::macros::paste!(
             /// Returns the name of this chipset, in lowercase.
             ///
             /// # Examples
@@ -64,7 +65,6 @@ pub(crate) const fn name(&self) -> &'static str {
                 )*
                 }
             }
-            );
         }
 
         // TODO[FPRI]: replace with something like derive(FromPrimitive)
@@ -73,45 +73,49 @@ impl TryFrom<u32> for Chipset {
 
             fn try_from(value: u32) -> Result<Self, Self::Error> {
                 match value {
-                    $( $value => Ok(Chipset::$variant), )*
+                    $(
+                        uapi::[<drm_nova_chipid_NOVA_DRM_CHIPID_ $variant:upper>]
+                            => Ok(Chipset::$variant),
+                    )*
                     _ => Err(ENODEV),
                 }
             }
         }
+    );
     }
 }
 
 define_chipset!({
     // Turing
-    TU102 = 0x162,
-    TU104 = 0x164,
-    TU106 = 0x166,
-    TU117 = 0x167,
-    TU116 = 0x168,
+    TU102,
+    TU104,
+    TU106,
+    TU117,
+    TU116,
     // Ampere
-    GA100 = 0x170,
-    GA102 = 0x172,
-    GA103 = 0x173,
-    GA104 = 0x174,
-    GA106 = 0x176,
-    GA107 = 0x177,
+    GA100,
+    GA102,
+    GA103,
+    GA104,
+    GA106,
+    GA107,
     // Hopper
-    GH100 = 0x180,
+    GH100,
     // Ada
-    AD102 = 0x192,
-    AD103 = 0x193,
-    AD104 = 0x194,
-    AD106 = 0x196,
-    AD107 = 0x197,
+    AD102,
+    AD103,
+    AD104,
+    AD106,
+    AD107,
     // Blackwell GB10x
-    GB100 = 0x1a0,
-    GB102 = 0x1a2,
+    GB100,
+    GB102,
     // Blackwell GB20x
-    GB202 = 0x1b2,
-    GB203 = 0x1b3,
-    GB205 = 0x1b5,
-    GB206 = 0x1b6,
-    GB207 = 0x1b7,
+    GB202,
+    GB203,
+    GB205,
+    GB206,
+    GB207,
 });
 
 impl Chipset {
diff --git a/include/uapi/drm/nova_drm.h b/include/uapi/drm/nova_drm.h
index 3ca90ed9d2bb..ea7665383644 100644
--- a/include/uapi/drm/nova_drm.h
+++ b/include/uapi/drm/nova_drm.h
@@ -25,6 +25,44 @@ extern "C" {
  */
 #define NOVA_GETPARAM_VRAM_BAR_SIZE	0x1
 
+/*
+ * Opaque chipids. These may be used to determine what chip a particular GPU is
+ * based on the identifier but the values themselves should not be assumed to
+ * carry any particular meaning.
+ */
+enum drm_nova_chipid {
+	/* Turing */
+	NOVA_DRM_CHIPID_TU102 = 0x162,
+	NOVA_DRM_CHIPID_TU104 = 0x164,
+	NOVA_DRM_CHIPID_TU106 = 0x166,
+	NOVA_DRM_CHIPID_TU117 = 0x167,
+	NOVA_DRM_CHIPID_TU116 = 0x168,
+	/* Ampere */
+	NOVA_DRM_CHIPID_GA100 = 0x170,
+	NOVA_DRM_CHIPID_GA102 = 0x172,
+	NOVA_DRM_CHIPID_GA103 = 0x173,
+	NOVA_DRM_CHIPID_GA104 = 0x174,
+	NOVA_DRM_CHIPID_GA106 = 0x176,
+	NOVA_DRM_CHIPID_GA107 = 0x177,
+	/* Hopper */
+	NOVA_DRM_CHIPID_GH100 = 0x180,
+	/* Ada */
+	NOVA_DRM_CHIPID_AD102 = 0x192,
+	NOVA_DRM_CHIPID_AD103 = 0x193,
+	NOVA_DRM_CHIPID_AD104 = 0x194,
+	NOVA_DRM_CHIPID_AD106 = 0x196,
+	NOVA_DRM_CHIPID_AD107 = 0x197,
+	/* Blackwell GB10x */
+	NOVA_DRM_CHIPID_GB100 = 0x1a0,
+	NOVA_DRM_CHIPID_GB102 = 0x1a2,
+	/* Blackwell GB20x */
+	NOVA_DRM_CHIPID_GB202 = 0x1b2,
+	NOVA_DRM_CHIPID_GB203 = 0x1b3,
+	NOVA_DRM_CHIPID_GB205 = 0x1b5,
+	NOVA_DRM_CHIPID_GB206 = 0x1b6,
+	NOVA_DRM_CHIPID_GB207 = 0x1b7,
+};
+
 /**
  * struct drm_nova_getparam - query GPU and driver metadata
  */
-- 
2.54.0

[PATCH v4 4/7] drm: nova: Add a GPU info ioctl

[Alistair Popple]

Add an ioctl to read basic GPU information. One of the first things a
user needs to know about a GPU is its chipid, so add that as the first
piece of information to return.

Other bits of information will be added over time. To facilitate this
the gpu info struct contains a size field to indicate how much of the
struct the kernel has filled in. A user passing in a larger struct will
just get a subset of the fields supported by the kernel returned. Users
passing a smaller struct than supported will just get fields truncated.

This also allows a user to probe the size of the required struct so long
as the data struct passed in is large enough to hold the size.

Signed-off-by: Alistair Popple <apopple@nvidia.com>

---

Changes since v3:

 - New for v4 - was previously returned as a GETPARAM parameter
---
 drivers/gpu/drm/nova/driver.rs |  2 +-
 drivers/gpu/drm/nova/file.rs   | 17 +++++++++++++++++
 drivers/gpu/nova-core/api.rs   | 11 +++++++++--
 drivers/gpu/nova-core/gpu.rs   |  8 ++++----
 include/uapi/drm/nova_drm.h    | 27 +++++++++++++++++++++++++++
 5 files changed, 58 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nova/driver.rs b/drivers/gpu/drm/nova/driver.rs
index 632137d1c6d7..d6dce160f371 100644
--- a/drivers/gpu/drm/nova/driver.rs
+++ b/drivers/gpu/drm/nova/driver.rs
@@ -32,7 +32,6 @@ pub(crate) struct Nova<'bound> {
 
 /// DRM registration data, accessible from ioctl handlers via the registration guard.
 pub(crate) struct DrmRegData<'bound> {
-    #[expect(unused)]
     pub(crate) api: Pin<&'bound NovaCoreApi<'bound>>,
 }
 
@@ -98,5 +97,6 @@ impl drm::Driver for NovaDriver {
         (NOVA_GETPARAM, drm_nova_getparam, ioctl::RENDER_ALLOW, File::get_param),
         (NOVA_GEM_CREATE, drm_nova_gem_create, ioctl::AUTH | ioctl::RENDER_ALLOW, File::gem_create),
         (NOVA_GEM_INFO, drm_nova_gem_info, ioctl::AUTH | ioctl::RENDER_ALLOW, File::gem_info),
+        (NOVA_GPU_INFO, drm_nova_gpu_info, ioctl::RENDER_ALLOW, File::gpu_info),
     }
 }
diff --git a/drivers/gpu/drm/nova/file.rs b/drivers/gpu/drm/nova/file.rs
index 1156df51c533..97688edd07af 100644
--- a/drivers/gpu/drm/nova/file.rs
+++ b/drivers/gpu/drm/nova/file.rs
@@ -78,4 +78,21 @@ pub(crate) fn gem_info(
 
         Ok(0)
     }
+
+    /// IOCTL: gpu_info: Query GPU info.
+    pub(crate) fn gpu_info(
+        _dev: &NovaDevice<Registered>,
+        reg_data: &DrmRegData<'_>,
+        gpu_info: &mut uapi::drm_nova_gpu_info,
+        _file: &drm::File<File>,
+    ) -> Result<u32> {
+        if gpu_info.pad != 0 {
+            return Err(EINVAL);
+        }
+
+        gpu_info.size = size_of::<uapi::drm_nova_gpu_info>() as u64;
+        gpu_info.chipid = reg_data.api.chipset() as u32;
+
+        Ok(0)
+    }
 }
diff --git a/drivers/gpu/nova-core/api.rs b/drivers/gpu/nova-core/api.rs
index 610cfc01111e..09da0b4e9103 100644
--- a/drivers/gpu/nova-core/api.rs
+++ b/drivers/gpu/nova-core/api.rs
@@ -12,11 +12,13 @@
     types::CovariantForLt, //
 };
 
-use crate::gpu::Gpu;
+use crate::gpu::{
+    Chipset,
+    Gpu, //
+};
 
 /// API handle for the auxiliary bus child drivers to interact with nova-core.
 pub struct NovaCoreApi<'bound> {
-    #[expect(unused)]
     pub(crate) gpu: Pin<&'bound Gpu<'bound>>,
 }
 
@@ -26,4 +28,9 @@ impl NovaCoreApi<'_> {
     pub fn of(adev: &auxiliary::Device<Bound>) -> Result<Pin<&NovaCoreApi<'_>>> {
         adev.registration_data::<CovariantForLt!(NovaCoreApi<'_>)>()
     }
+
+    /// Returns the chipset of this GPU.
+    pub fn chipset(&self) -> Chipset {
+        self.gpu.spec.chipset
+    }
 }
diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 738a590e753b..34a496ec3b38 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -41,7 +41,7 @@ macro_rules! define_chipset {
         ::kernel::macros::paste!(
         /// Enum representation of the GPU chipset.
         #[derive(fmt::Debug, Copy, Clone, PartialOrd, Ord, PartialEq, Eq)]
-        pub(crate) enum Chipset {
+        pub enum Chipset {
             $($variant = uapi::[<drm_nova_chipid_NOVA_DRM_CHIPID_ $variant:upper>] as isize),*,
         }
 
@@ -161,7 +161,7 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
 bounded_enum! {
     /// Enum representation of the GPU generation.
     #[derive(fmt::Debug, Copy, Clone)]
-    pub(crate) enum Architecture with TryFrom<Bounded<u32, 6>> {
+    pub enum Architecture with TryFrom<Bounded<u32, 6>> {
         Turing = 0x16,
         Ampere = 0x17,
         Hopper = 0x18,
@@ -195,7 +195,7 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
 /// Structure holding a basic description of the GPU: `Chipset` and `Revision`.
 #[derive(Clone, Copy)]
 pub(crate) struct Spec {
-    chipset: Chipset,
+    pub(crate) chipset: Chipset,
     revision: Revision,
 }
 
@@ -281,7 +281,7 @@ struct GspResources<'gpu> {
 /// Structure holding the resources required to operate the GPU.
 #[pin_data]
 pub(crate) struct Gpu<'gpu> {
-    spec: Spec,
+    pub(crate) spec: Spec,
     /// Static GPU information as provided by the GSP.
     gsp_static_info: GetGspStaticInfoReply,
     /// GSP and its resources.
diff --git a/include/uapi/drm/nova_drm.h b/include/uapi/drm/nova_drm.h
index ea7665383644..2604e4d2698b 100644
--- a/include/uapi/drm/nova_drm.h
+++ b/include/uapi/drm/nova_drm.h
@@ -118,9 +118,34 @@ struct drm_nova_gem_info {
 	__u64 size;
 };
 
+/**
+ * struct drm_nova_gpu_info - query DRM GPU info.
+ */
+struct drm_nova_gpu_info {
+	/**
+	 * @size: The amount of space allocated by userspace for this structure.
+	 * The kernel will return the amount of data it did/could actually write.
+	 * User space can use this to determine how much of the struct is valid
+	 * when running against an older kernel.
+	 */
+	__u64 size;
+
+	/**
+	 * @chipid: GPU chip identifier. See &enum drm_nova_chipid for currently
+	 * known chip identifiers.
+	 */
+	__u32 chipid;
+
+	/**
+	 * @pad: 32 bit padding, must be 0.
+	 */
+	__u32 pad;
+};
+
 #define DRM_NOVA_GETPARAM		0x00
 #define DRM_NOVA_GEM_CREATE		0x01
 #define DRM_NOVA_GEM_INFO		0x02
+#define DRM_NOVA_GPU_INFO		0x03
 
 /* Note: this is an enum so that it can be resolved by Rust bindgen. */
 enum {
@@ -130,6 +155,8 @@ enum {
 						   struct drm_nova_gem_create),
 	DRM_IOCTL_NOVA_GEM_INFO		= DRM_IOWR(DRM_COMMAND_BASE + DRM_NOVA_GEM_INFO,
 						   struct drm_nova_gem_info),
+	DRM_IOCTL_NOVA_GPU_INFO		= DRM_IOWR(DRM_COMMAND_BASE + DRM_NOVA_GPU_INFO,
+						   struct drm_nova_gpu_info),
 };
 
 #if defined(__cplusplus)
-- 
2.54.0

[PATCH v4 5/7] drm: nova: Add usable VRAM size to GPU info ioctl

[Alistair Popple]

Add a parameter to the GPU info ioctl to return the total usable
framebuffer size. The usable framebuffer excludes GSP carveouts and
other protected regions so may differ in size from BAR size and total
physical VRAM.

Signed-off-by: Alistair Popple <apopple@nvidia.com>

---

Changes since v3:

 - Partially new for v4 - previously this used GETPARAM
---
 drivers/gpu/drm/nova/file.rs          | 1 +
 drivers/gpu/nova-core/api.rs          | 5 +++++
 drivers/gpu/nova-core/gpu.rs          | 6 ++----
 drivers/gpu/nova-core/gsp/commands.rs | 8 ++++++++
 include/uapi/drm/nova_drm.h           | 6 ++++++
 5 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nova/file.rs b/drivers/gpu/drm/nova/file.rs
index 97688edd07af..cbe45d022ac6 100644
--- a/drivers/gpu/drm/nova/file.rs
+++ b/drivers/gpu/drm/nova/file.rs
@@ -92,6 +92,7 @@ pub(crate) fn gpu_info(
 
         gpu_info.size = size_of::<uapi::drm_nova_gpu_info>() as u64;
         gpu_info.chipid = reg_data.api.chipset() as u32;
+        gpu_info.vram_size = reg_data.api.vram_size();
 
         Ok(0)
     }
diff --git a/drivers/gpu/nova-core/api.rs b/drivers/gpu/nova-core/api.rs
index 09da0b4e9103..f025df90dc5d 100644
--- a/drivers/gpu/nova-core/api.rs
+++ b/drivers/gpu/nova-core/api.rs
@@ -33,4 +33,9 @@ pub fn of(adev: &auxiliary::Device<Bound>) -> Result<Pin<&NovaCoreApi<'_>>> {
     pub fn chipset(&self) -> Chipset {
         self.gpu.spec.chipset
     }
+
+    /// Returns the total usable VRAM size of this GPU in bytes.
+    pub fn vram_size(&self) -> u64 {
+        self.gpu.gsp_static_info.vram_size()
+    }
 }
diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 34a496ec3b38..7a2037105d29 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -283,7 +283,7 @@ struct GspResources<'gpu> {
 pub(crate) struct Gpu<'gpu> {
     pub(crate) spec: Spec,
     /// Static GPU information as provided by the GSP.
-    gsp_static_info: GetGspStaticInfoReply,
+    pub(crate) gsp_static_info: GetGspStaticInfoReply,
     /// GSP and its resources.
     #[pin]
     gsp_resources: GspResources<'gpu>,
@@ -400,9 +400,7 @@ pub(crate) fn new(
                     dev_dbg!(
                         dev,
                         "Total usable VRAM: {} MiB\n",
-                        info.usable_fb_regions.iter().fold(0u64, |res, region| res
-                            .saturating_add(region.end - region.start))
-                            / u64::SZ_1M
+                        info.vram_size() / u64::SZ_1M
                     );
                 }
 
diff --git a/drivers/gpu/nova-core/gsp/commands.rs b/drivers/gpu/nova-core/gsp/commands.rs
index 08380de39048..49ff3f5edcec 100644
--- a/drivers/gpu/nova-core/gsp/commands.rs
+++ b/drivers/gpu/nova-core/gsp/commands.rs
@@ -252,6 +252,14 @@ pub(crate) fn gpu_name(&self) -> core::result::Result<&str, GpuNameError> {
             .to_str()
             .map_err(GpuNameError::InvalidUtf8)
     }
+
+    /// Returns the total usable VRAM size in bytes, i.e. the summed lengths of all usable FB
+    /// regions.
+    pub(crate) fn vram_size(&self) -> u64 {
+        self.usable_fb_regions.iter().fold(0, |size, region| {
+            size.saturating_add(region.end - region.start)
+        })
+    }
 }
 
 pub(crate) use fw::commands::PowerStateLevel;
diff --git a/include/uapi/drm/nova_drm.h b/include/uapi/drm/nova_drm.h
index 2604e4d2698b..e315556dac26 100644
--- a/include/uapi/drm/nova_drm.h
+++ b/include/uapi/drm/nova_drm.h
@@ -140,6 +140,12 @@ struct drm_nova_gpu_info {
 	 * @pad: 32 bit padding, must be 0.
 	 */
 	__u32 pad;
+
+	/**
+	 * @vram_size: Amount of usable FB, excluding GSP carveouts and protected
+	 * regions.
+	 */
+	__u64 vram_size;
 };
 
 #define DRM_NOVA_GETPARAM		0x00
-- 
2.54.0

[PATCH v4 6/7] drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter

[Alistair Popple]

Currently nova-drm reads the VRAM BAR size directly from the PCIe device
which requires trying to cast the parent device into a PCIe device. This
obviously requires the parent device to actually be a PCIe bus device.
Whilst that is true today it may not always be the case, and there
is no reason to make this assumption now that NovaCoreApi can hold a
reference to the bound PCIe device.

So convert nova-drm to using nova-core to obtain the VRAM_BAR_SIZE
parameter.

Signed-off-by: Alistair Popple <apopple@nvidia.com>

---

Changes from v2:

 - Update nova-core API to use bar1_size() instead of vram_bar_size() as
   this is used internally throughout our chip HW.
---
 drivers/gpu/drm/nova/file.rs    | 12 +++---------
 drivers/gpu/nova-core/api.rs    |  8 ++++++++
 drivers/gpu/nova-core/driver.rs |  2 +-
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/nova/file.rs b/drivers/gpu/drm/nova/file.rs
index cbe45d022ac6..9e8d140e517a 100644
--- a/drivers/gpu/drm/nova/file.rs
+++ b/drivers/gpu/drm/nova/file.rs
@@ -8,14 +8,11 @@
 use crate::gem::NovaObject;
 use kernel::{
     alloc::flags::*,
-    auxiliary,
-    device::Bound,
     drm::{
         self,
         gem::BaseObject,
         Registered, //
     },
-    pci,
     prelude::*,
     uapi,
 };
@@ -33,16 +30,13 @@ fn open(_dev: &NovaDevice) -> Result<Pin<KBox<Self>>> {
 impl File {
     /// IOCTL: get_param: Query GPU / driver metadata.
     pub(crate) fn get_param(
-        dev: &NovaDevice<Registered>,
-        _reg_data: &DrmRegData<'_>,
+        _dev: &NovaDevice<Registered>,
+        reg_data: &DrmRegData<'_>,
         getparam: &mut uapi::drm_nova_getparam,
         _file: &drm::File<File>,
     ) -> Result<u32> {
-        let adev: &auxiliary::Device<Bound> = dev.as_ref();
-        let pdev: &pci::Device<Bound> = adev.parent().try_into()?;
-
         let value = match getparam.param as u32 {
-            uapi::NOVA_GETPARAM_VRAM_BAR_SIZE => pdev.resource_len(1)?,
+            uapi::NOVA_GETPARAM_VRAM_BAR_SIZE => reg_data.api.bar1_size()?,
             _ => return Err(EINVAL),
         };
 
diff --git a/drivers/gpu/nova-core/api.rs b/drivers/gpu/nova-core/api.rs
index f025df90dc5d..9e2a5ba7c269 100644
--- a/drivers/gpu/nova-core/api.rs
+++ b/drivers/gpu/nova-core/api.rs
@@ -8,6 +8,7 @@
 use kernel::{
     auxiliary,
     device::Bound,
+    pci,
     prelude::*,
     types::CovariantForLt, //
 };
@@ -20,6 +21,7 @@
 /// API handle for the auxiliary bus child drivers to interact with nova-core.
 pub struct NovaCoreApi<'bound> {
     pub(crate) gpu: Pin<&'bound Gpu<'bound>>,
+    pub(crate) pdev: &'bound pci::Device<Bound>,
 }
 
 impl NovaCoreApi<'_> {
@@ -34,6 +36,12 @@ pub fn chipset(&self) -> Chipset {
         self.gpu.spec.chipset
     }
 
+    /// Returns the size of the PCIe BAR used for accessing VRAM, typically
+    /// BAR1.
+    pub fn bar1_size(&self) -> Result<u64> {
+        self.pdev.resource_len(1)
+    }
+
     /// Returns the total usable VRAM size of this GPU in bytes.
     pub fn vram_size(&self) -> u64 {
         self.gpu.gsp_static_info.vram_size()
diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
index 435aa917d3e7..175275fd7961 100644
--- a/drivers/gpu/nova-core/driver.rs
+++ b/drivers/gpu/nova-core/driver.rs
@@ -113,7 +113,7 @@ fn probe<'bound>(
                             // never recycles IDs.
                             AUXILIARY_ID_COUNTER.fetch_add(1, Relaxed),
                             crate::MODULE_NAME,
-                            NovaCoreApi { gpu },
+                            NovaCoreApi { gpu, pdev },
                         )?
                     }
                 },
-- 
2.54.0

[PATCH v4 7/7] drm: nova: Expose a render node

[Alistair Popple]

nova-drm currently only exposes a primary node even though all of its
ioctls are already marked DRM_RENDER_ALLOW. Set the DRIVER_RENDER
feature so that a render node (/dev/dri/renderDXX) is created as well.

This is required to allow render and compute clients to interact with
nova-drm.

Signed-off-by: Alistair Popple <apopple@nvidia.com>

---

Changes since v2:

 - New for v3.
---
 drivers/gpu/drm/nova/driver.rs | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nova/driver.rs b/drivers/gpu/drm/nova/driver.rs
index d6dce160f371..cbe2b249f7da 100644
--- a/drivers/gpu/drm/nova/driver.rs
+++ b/drivers/gpu/drm/nova/driver.rs
@@ -92,6 +92,7 @@ impl drm::Driver for NovaDriver {
     type ParentDevice<Ctx: DeviceContext> = auxiliary::Device<Ctx>;
 
     const INFO: drm::DriverInfo = INFO;
+    const FEAT_RENDER: bool = true;
 
     kernel::declare_drm_ioctls! {
         (NOVA_GETPARAM, drm_nova_getparam, ioctl::RENDER_ALLOW, File::get_param),
-- 
2.54.0

Re: [PATCH v4 6/7] drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter

[Danilo Krummrich]

On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote:
> Currently nova-drm reads the VRAM BAR size directly from the PCIe device
> which requires trying to cast the parent device into a PCIe device. This
> obviously requires the parent device to actually be a PCIe bus device.
> Whilst that is true today it may not always be the case, and there
> is no reason to make this assumption now that NovaCoreApi can hold a
> reference to the bound PCIe device.
>
> So convert nova-drm to using nova-core to obtain the VRAM_BAR_SIZE
> parameter.
>
> Signed-off-by: Alistair Popple <apopple@nvidia.com>

Suggested-by: Danilo Krummrich <dakr@kernel.org>

> @@ -33,16 +30,13 @@ fn open(_dev: &NovaDevice) -> Result<Pin<KBox<Self>>> {
>  impl File {
>      /// IOCTL: get_param: Query GPU / driver metadata.
>      pub(crate) fn get_param(
> -        dev: &NovaDevice<Registered>,
> -        _reg_data: &DrmRegData<'_>,
> +        _dev: &NovaDevice<Registered>,
> +        reg_data: &DrmRegData<'_>,
>          getparam: &mut uapi::drm_nova_getparam,
>          _file: &drm::File<File>,
>      ) -> Result<u32> {
> -        let adev: &auxiliary::Device<Bound> = dev.as_ref();
> -        let pdev: &pci::Device<Bound> = adev.parent().try_into()?;
> -
>          let value = match getparam.param as u32 {
> -            uapi::NOVA_GETPARAM_VRAM_BAR_SIZE => pdev.resource_len(1)?,
> +            uapi::NOVA_GETPARAM_VRAM_BAR_SIZE => reg_data.api.bar1_size()?,
>              _ => return Err(EINVAL),
>          };

That's much cleaner, thanks for adding this patch!

Once this landed we can remove the

	impl<Ctx: device::DeviceContext> TryFrom<&device::Device<Ctx>> for &Device<Ctx>

impl in rust/kernel/pci.rs. (I think platform should have the same impl to get
rid of independently.)

If your are interested, feel free to send a follow-up patch (or include it in
this series).

Re: [PATCH v4 4/7] drm: nova: Add a GPU info ioctl

[Danilo Krummrich]

On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote:
> diff --git a/include/uapi/drm/nova_drm.h b/include/uapi/drm/nova_drm.h
> index ea7665383644..2604e4d2698b 100644
> --- a/include/uapi/drm/nova_drm.h
> +++ b/include/uapi/drm/nova_drm.h
> @@ -118,9 +118,34 @@ struct drm_nova_gem_info {
>  	__u64 size;
>  };
>  
> +/**
> + * struct drm_nova_gpu_info - query DRM GPU info.
> + */
> +struct drm_nova_gpu_info {
> +	/**
> +	 * @size: The amount of space allocated by userspace for this structure.
> +	 * The kernel will return the amount of data it did/could actually write.
> +	 * User space can use this to determine how much of the struct is valid
> +	 * when running against an older kernel.
> +	 */
> +	__u64 size;
> +
> +	/**
> +	 * @chipid: GPU chip identifier. See &enum drm_nova_chipid for currently
> +	 * known chip identifiers.
> +	 */
> +	__u32 chipid;
> +
> +	/**
> +	 * @pad: 32 bit padding, must be 0.
> +	 */
> +	__u32 pad;
> +};

I think we should add the indirection we discussed in [1], i.e. have an
indirection via

	struct drm_nova_info {
		__u32 id;
		__u32 size;
		__u64 info;
		/* Revserved fields, just in case? */
	};

so we can easily add new info structures, or extend an existing one with a v2
without having to create new ioctls for this purpose.

[1] https://lore.kernel.org/nova-gpu/DKC6T1DQX2L3.HTHPB2L167TC@kernel.org/

>  #define DRM_NOVA_GETPARAM		0x00
>  #define DRM_NOVA_GEM_CREATE		0x01
>  #define DRM_NOVA_GEM_INFO		0x02
> +#define DRM_NOVA_GPU_INFO		0x03
>  
>  /* Note: this is an enum so that it can be resolved by Rust bindgen. */
>  enum {
> @@ -130,6 +155,8 @@ enum {
>  						   struct drm_nova_gem_create),
>  	DRM_IOCTL_NOVA_GEM_INFO		= DRM_IOWR(DRM_COMMAND_BASE + DRM_NOVA_GEM_INFO,
>  						   struct drm_nova_gem_info),
> +	DRM_IOCTL_NOVA_GPU_INFO		= DRM_IOWR(DRM_COMMAND_BASE + DRM_NOVA_GPU_INFO,
> +						   struct drm_nova_gpu_info),
>  };
>  
>  #if defined(__cplusplus)
> -- 
> 2.54.0

Re: [PATCH v4 4/7] drm: nova: Add a GPU info ioctl

[Alistair Popple]

On 2026-08-18 at 06:18 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote:
> > diff --git a/include/uapi/drm/nova_drm.h b/include/uapi/drm/nova_drm.h
> > index ea7665383644..2604e4d2698b 100644
> > --- a/include/uapi/drm/nova_drm.h
> > +++ b/include/uapi/drm/nova_drm.h
> > @@ -118,9 +118,34 @@ struct drm_nova_gem_info {
> >  	__u64 size;
> >  };
> >  
> > +/**
> > + * struct drm_nova_gpu_info - query DRM GPU info.
> > + */
> > +struct drm_nova_gpu_info {
> > +	/**
> > +	 * @size: The amount of space allocated by userspace for this structure.
> > +	 * The kernel will return the amount of data it did/could actually write.
> > +	 * User space can use this to determine how much of the struct is valid
> > +	 * when running against an older kernel.
> > +	 */
> > +	__u64 size;
> > +
> > +	/**
> > +	 * @chipid: GPU chip identifier. See &enum drm_nova_chipid for currently
> > +	 * known chip identifiers.
> > +	 */
> > +	__u32 chipid;
> > +
> > +	/**
> > +	 * @pad: 32 bit padding, must be 0.
> > +	 */
> > +	__u32 pad;
> > +};
> 
> I think we should add the indirection we discussed in [1], i.e. have an
> indirection via
> 
> 	struct drm_nova_info {
> 		__u32 id;
> 		__u32 size;
> 		__u64 info;
> 		/* Revserved fields, just in case? */
> 	};
> 
> so we can easily add new info structures, or extend an existing one with a v2
> without having to create new ioctls for this purpose.

Sorry, I should have called this difference out more explicitly.

Basically I ended up doing it this way because it didn't make much sense to me
putting an ioctl interface within an ioctl interface when DRM ioctl handling
can already deal with matching numbers and truncating/extending the struct as
required. It just leads to more code comparing ID's, etc and I'm not really sure
what the advantage is. Are we concerned about running out of ioctls if we have
to add other types of info struct?

Doing this as top-level ioctl makes the strace decoders simpler and means we can
just rely on the existing DRM ioctl handling to get everything right rather than
duplicating that in nova-drm. Or is there some other advantage to [1] that I've
missed that isn't solved here?

Thanks for looking.

 - Alistair

> 
> [1] https://lore.kernel.org/nova-gpu/DKC6T1DQX2L3.HTHPB2L167TC@kernel.org/
> 
> >  #define DRM_NOVA_GETPARAM		0x00
> >  #define DRM_NOVA_GEM_CREATE		0x01
> >  #define DRM_NOVA_GEM_INFO		0x02
> > +#define DRM_NOVA_GPU_INFO		0x03
> >  
> >  /* Note: this is an enum so that it can be resolved by Rust bindgen. */
> >  enum {
> > @@ -130,6 +155,8 @@ enum {
> >  						   struct drm_nova_gem_create),
> >  	DRM_IOCTL_NOVA_GEM_INFO		= DRM_IOWR(DRM_COMMAND_BASE + DRM_NOVA_GEM_INFO,
> >  						   struct drm_nova_gem_info),
> > +	DRM_IOCTL_NOVA_GPU_INFO		= DRM_IOWR(DRM_COMMAND_BASE + DRM_NOVA_GPU_INFO,
> > +						   struct drm_nova_gpu_info),
> >  };
> >  
> >  #if defined(__cplusplus)
> > -- 
> > 2.54.0
> 

Re: [PATCH v4 6/7] drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter

[Alistair Popple]

On 2026-08-18 at 06:11 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote:
> > Currently nova-drm reads the VRAM BAR size directly from the PCIe device
> > which requires trying to cast the parent device into a PCIe device. This
> > obviously requires the parent device to actually be a PCIe bus device.
> > Whilst that is true today it may not always be the case, and there
> > is no reason to make this assumption now that NovaCoreApi can hold a
> > reference to the bound PCIe device.
> >
> > So convert nova-drm to using nova-core to obtain the VRAM_BAR_SIZE
> > parameter.
> >
> > Signed-off-by: Alistair Popple <apopple@nvidia.com>
> 
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> 
> > @@ -33,16 +30,13 @@ fn open(_dev: &NovaDevice) -> Result<Pin<KBox<Self>>> {
> >  impl File {
> >      /// IOCTL: get_param: Query GPU / driver metadata.
> >      pub(crate) fn get_param(
> > -        dev: &NovaDevice<Registered>,
> > -        _reg_data: &DrmRegData<'_>,
> > +        _dev: &NovaDevice<Registered>,
> > +        reg_data: &DrmRegData<'_>,
> >          getparam: &mut uapi::drm_nova_getparam,
> >          _file: &drm::File<File>,
> >      ) -> Result<u32> {
> > -        let adev: &auxiliary::Device<Bound> = dev.as_ref();
> > -        let pdev: &pci::Device<Bound> = adev.parent().try_into()?;
> > -
> >          let value = match getparam.param as u32 {
> > -            uapi::NOVA_GETPARAM_VRAM_BAR_SIZE => pdev.resource_len(1)?,
> > +            uapi::NOVA_GETPARAM_VRAM_BAR_SIZE => reg_data.api.bar1_size()?,
> >              _ => return Err(EINVAL),
> >          };
> 
> That's much cleaner, thanks for adding this patch!

No problem! Agree it's much nicer.

> Once this landed we can remove the
> 
> 	impl<Ctx: device::DeviceContext> TryFrom<&device::Device<Ctx>> for &Device<Ctx>
> 
> impl in rust/kernel/pci.rs. (I think platform should have the same impl to get
> rid of independently.)
> 
> If your are interested, feel free to send a follow-up patch (or include it in
> this series).

Happy to do either. Seems like it might be easiest just to add it to this
series so will add it to v5.

Re: [PATCH v4 3/7] drm: nova: Add chipid enum to nova-drm UAPI

[M Henning]

On Tue, Aug 11, 2026 at 1:12 AM Alistair Popple <apopple@nvidia.com> wrote:
> +/*
> + * Opaque chipids. These may be used to determine what chip a particular GPU is
> + * based on the identifier but the values themselves should not be assumed to
> + * carry any particular meaning.
> + */

You say this is opaque, but the userspace MR you posted already treats
the values as non-opaque in eg. sm_for_chipset.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43352/diffs?commit_id=945a8e7c51939577526974b342c8dc6bafc3372f
So, I guess my question is, is is opaque or not?

I don't see much of a reason to make it opaque since the chipset has
had the same structure on the hardware level for 30 years, so I don't
expect it to change too often. Truly treating this as opaque would
likely require a small refactor on the userspace side without much
value. (I realize this has already been discussed a bit on the
previous version.)

Re: [PATCH v4 4/7] drm: nova: Add a GPU info ioctl

[Danilo Krummrich]

On Fri Aug 21, 2026 at 7:10 AM CEST, Alistair Popple wrote:
> On 2026-08-18 at 06:18 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
>> On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote:
>> > diff --git a/include/uapi/drm/nova_drm.h b/include/uapi/drm/nova_drm.h
>> > index ea7665383644..2604e4d2698b 100644
>> > --- a/include/uapi/drm/nova_drm.h
>> > +++ b/include/uapi/drm/nova_drm.h
>> > @@ -118,9 +118,34 @@ struct drm_nova_gem_info {
>> >  	__u64 size;
>> >  };
>> >  
>> > +/**
>> > + * struct drm_nova_gpu_info - query DRM GPU info.
>> > + */
>> > +struct drm_nova_gpu_info {
>> > +	/**
>> > +	 * @size: The amount of space allocated by userspace for this structure.
>> > +	 * The kernel will return the amount of data it did/could actually write.
>> > +	 * User space can use this to determine how much of the struct is valid
>> > +	 * when running against an older kernel.
>> > +	 */
>> > +	__u64 size;
>> > +
>> > +	/**
>> > +	 * @chipid: GPU chip identifier. See &enum drm_nova_chipid for currently
>> > +	 * known chip identifiers.
>> > +	 */
>> > +	__u32 chipid;

I think we now also want to add a field for the architecture now that chipid is
considered opaque.

>> > +
>> > +	/**
>> > +	 * @pad: 32 bit padding, must be 0.
>> > +	 */
>> > +	__u32 pad;
>> > +};
>> 
>> I think we should add the indirection we discussed in [1], i.e. have an
>> indirection via
>> 
>> 	struct drm_nova_info {
>> 		__u32 id;
>> 		__u32 size;
>> 		__u64 info;
>> 		/* Revserved fields, just in case? */
>> 	};
>> 
>> so we can easily add new info structures, or extend an existing one with a v2
>> without having to create new ioctls for this purpose.
>
> Sorry, I should have called this difference out more explicitly.
>
> Basically I ended up doing it this way because it didn't make much sense to me
> putting an ioctl interface within an ioctl interface when DRM ioctl handling
> can already deal with matching numbers and truncating/extending the struct as
> required. It just leads to more code comparing ID's, etc and I'm not really sure
> what the advantage is. Are we concerned about running out of ioctls if we have
> to add other types of info struct?
>
> Doing this as top-level ioctl makes the strace decoders simpler and means we can
> just rely on the existing DRM ioctl handling to get everything right rather than
> duplicating that in nova-drm. Or is there some other advantage to [1] that I've
> missed that isn't solved here?

I don't think we are really concerned about running out of ioctls, but it seems
cleaner and more self-contained than having N ioctls for different info structs
and in the worst case having v2...vN info ioctls.

It also allows us to define a new info type struct whenever we think something
is a new logical info group. Making it per ioctl will always raise the question
of "do we really need a new ioctl for this, can't we just fit it in X", which
over time tends to get messy.

I think eventually we will have a bunch of different info categories. OpenRM
seems to have quite some as well (not too many categories, but with lots of
fields), Xe and amdgpu have even more categories.

> Thanks for looking.
>
>  - Alistair
>
>> 
>> [1] https://lore.kernel.org/nova-gpu/DKC6T1DQX2L3.HTHPB2L167TC@kernel.org/
>> 
>> >  #define DRM_NOVA_GETPARAM		0x00
>> >  #define DRM_NOVA_GEM_CREATE		0x01
>> >  #define DRM_NOVA_GEM_INFO		0x02
>> > +#define DRM_NOVA_GPU_INFO		0x03
>> >  
>> >  /* Note: this is an enum so that it can be resolved by Rust bindgen. */
>> >  enum {
>> > @@ -130,6 +155,8 @@ enum {
>> >  						   struct drm_nova_gem_create),
>> >  	DRM_IOCTL_NOVA_GEM_INFO		= DRM_IOWR(DRM_COMMAND_BASE + DRM_NOVA_GEM_INFO,
>> >  						   struct drm_nova_gem_info),
>> > +	DRM_IOCTL_NOVA_GPU_INFO		= DRM_IOWR(DRM_COMMAND_BASE + DRM_NOVA_GPU_INFO,
>> > +						   struct drm_nova_gpu_info),
>> >  };
>> >  
>> >  #if defined(__cplusplus)
>> > -- 
>> > 2.54.0
>> 

Re: [PATCH v4 3/7] drm: nova: Add chipid enum to nova-drm UAPI

[Danilo Krummrich]

On Mon Aug 24, 2026 at 4:49 PM CEST, M Henning wrote:
> On Tue, Aug 11, 2026 at 1:12 AM Alistair Popple <apopple@nvidia.com> wrote:
>> +/*
>> + * Opaque chipids. These may be used to determine what chip a particular GPU is
>> + * based on the identifier but the values themselves should not be assumed to
>> + * carry any particular meaning.
>> + */
>
> You say this is opaque, but the userspace MR you posted already treats
> the values as non-opaque in eg. sm_for_chipset.
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43352/diffs?commit_id=945a8e7c51939577526974b342c8dc6bafc3372f
> So, I guess my question is, is is opaque or not?

The PR is outdated and goes back to the first version of this patch series;
what's written here is correct.

> I don't see much of a reason to make it opaque since the chipset has
> had the same structure on the hardware level for 30 years, so I don't
> expect it to change too often. Truly treating this as opaque would
> likely require a small refactor on the userspace side without much
> value. (I realize this has already been discussed a bit on the
> previous version.)

I don't see much value in having userspace decode this value (again) after the
kernel did it already and can easily provide the required information without
making userspace commit to some encoding in the hardware (even though I do agree
that it is unlikely).

OTH, the way chip IDs are derived has changed over the years (BOOT_0 / BOOT_42
with different register layouts), and I'd rather not have userspace commit to
any particular encoding when the kernel already provides the decoded
information.

Regarding the refactor in mesa, the Nova uAPI won't follow nouveau anyway, so I
don't want to limit ourselfs here.

Re: [PATCH v4 4/7] drm: nova: Add a GPU info ioctl

[Danilo Krummrich]

On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote:
>  include/uapi/drm/nova_drm.h    | 27 +++++++++++++++++++++++++++

Btw. I think it would be nice to have project to play around with and write
tests directly on top of the uAPI before we can run the big test suites.

When I implemented the VM_BIND uAPI for nouveau I used IGT for this (but didn't
enjoy it too much). It turned out to be very useful to test and benchmark the
implementation before being able to complete VK CTS.

When I sent the first nova-drm skeleton, I also submitted [1]; maybe we can
extend this further accordingly?

I'm also open for other ideas, but I'd really like to have something like this
as we develop nova-drm.

[1] https://gitlab.freedesktop.org/dakr/drm-test

Re: [PATCH v4 4/7] drm: nova: Add a GPU info ioctl

[John Hubbard]

On 8/24/26 12:34 PM, Danilo Krummrich wrote:
> On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote:
>>  include/uapi/drm/nova_drm.h    | 27 +++++++++++++++++++++++++++
> 
> Btw. I think it would be nice to have project to play around with and write
> tests directly on top of the uAPI before we can run the big test suites.

Yes, I think it's reasonable to do something like that. Seeing a new API
from both sides, caller and callee, is always illuminating during review,
for one thing.

> 
> When I implemented the VM_BIND uAPI for nouveau I used IGT for this (but didn't
> enjoy it too much). It turned out to be very useful to test and benchmark the
> implementation before being able to complete VK CTS.
> 
> When I sent the first nova-drm skeleton, I also submitted [1]; maybe we can
> extend this further accordingly?
> 
> I'm also open for other ideas, but I'd really like to have something like this
> as we develop nova-drm.
> 
> [1] https://gitlab.freedesktop.org/dakr/drm-test

I was thinking about where this sort of thing should go, and this
location seems as good, or slightly better than the main alternatives,
to get started anyway.

Alternatives include:

1) The kernel's kselftests (tools/testings/selftests). These are
helpful in many cases, but some minor issues include:

    a) Oddly tight coupling to kernel code, even though the whole
       point of these is to exercise the kernel from user space.
       (Otherwise, these days one would use KUnit.) I've personally
       working on mitigating the coupling-induced problems and 
       ran into other, bigger problems along the way, such as:

   b) Confused build system and an arguably wrong way of invoking
      the tests (from Make(1) !).

2) Some other github-like location to host user space tests for
   nova. The idea is, do we want to set up a well-known location
   that people should keep updated? Or let a thousand github
   small test sites bloom? 


thanks,
-- 
John Hubbard

Re: [PATCH v4 4/7] drm: nova: Add a GPU info ioctl

[Alistair Popple]

On 2026-08-25 at 06:04 +1000, John Hubbard <jhubbard@nvidia.com> wrote...
> On 8/24/26 12:34 PM, Danilo Krummrich wrote:
> > On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote:
> >>  include/uapi/drm/nova_drm.h    | 27 +++++++++++++++++++++++++++
> > 
> > Btw. I think it would be nice to have project to play around with and write
> > tests directly on top of the uAPI before we can run the big test suites.
> 
> Yes, I think it's reasonable to do something like that. Seeing a new API
> from both sides, caller and callee, is always illuminating during review,
> for one thing.

Yes, I had meant to do this so thanks for the reminder.
You can of course see the other side of the API here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43352

But that's a user of the UAPI rather than a tester of it which makes it hard to
exercise everything or specific parts of the API. I did actually end up writing
my own standalone test case for these, similar to [1] but never got around to
tidying it up and posting it. Looking at [1] it seems reasonable as a simple
stand-alone test so I will do that ahead of the next revision for this series.

> > 
> > When I implemented the VM_BIND uAPI for nouveau I used IGT for this (but didn't
> > enjoy it too much). It turned out to be very useful to test and benchmark the
> > implementation before being able to complete VK CTS.
> > 
> > When I sent the first nova-drm skeleton, I also submitted [1]; maybe we can
> > extend this further accordingly?
> > 
> > I'm also open for other ideas, but I'd really like to have something like this
> > as we develop nova-drm.
> > 
> > [1] https://gitlab.freedesktop.org/dakr/drm-test
> 
> I was thinking about where this sort of thing should go, and this
> location seems as good, or slightly better than the main alternatives,
> to get started anyway.
> 
> Alternatives include:
> 
> 1) The kernel's kselftests (tools/testings/selftests). These are
> helpful in many cases, but some minor issues include:

Yeah, I don't think these style of tests belong in kselftests if only because
they're never going to be self-contained as at a minimum they will require
specific HW. It might make sense for unit-test style things, but I (think)
Rust-for-Linux already has that covered.

>     a) Oddly tight coupling to kernel code, even though the whole
>        point of these is to exercise the kernel from user space.
>        (Otherwise, these days one would use KUnit.) I've personally
>        working on mitigating the coupling-induced problems and 
>        ran into other, bigger problems along the way, such as:
> 
>    b) Confused build system and an arguably wrong way of invoking
>       the tests (from Make(1) !).
> 
> 2) Some other github-like location to host user space tests for
>    nova. The idea is, do we want to set up a well-known location
>    that people should keep updated? Or let a thousand github
>    small test sites bloom? 

We obviously can't stop a thousand small test sites blooming if people create
them, but I think it would be good to establish a well-known location for core
Nova developers to contribute to at least.

> thanks,
> -- 
> John Hubbard
> 

Re: [PATCH v4 3/7] drm: nova: Add chipid enum to nova-drm UAPI

[Alistair Popple]

On 2026-08-25 at 05:24 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> On Mon Aug 24, 2026 at 4:49 PM CEST, M Henning wrote:
> > On Tue, Aug 11, 2026 at 1:12 AM Alistair Popple <apopple@nvidia.com> wrote:
> >> +/*
> >> + * Opaque chipids. These may be used to determine what chip a particular GPU is
> >> + * based on the identifier but the values themselves should not be assumed to
> >> + * carry any particular meaning.
> >> + */
> >
> > You say this is opaque, but the userspace MR you posted already treats
> > the values as non-opaque in eg. sm_for_chipset.
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43352/diffs?commit_id=945a8e7c51939577526974b342c8dc6bafc3372f
> > So, I guess my question is, is is opaque or not?
> 
> The PR is outdated and goes back to the first version of this patch series;
> what's written here is correct.

Right - I was holding off on updating the PR until we'd settled on the UAPI
here.

> > I don't see much of a reason to make it opaque since the chipset has
> > had the same structure on the hardware level for 30 years, so I don't
> > expect it to change too often. Truly treating this as opaque would
> > likely require a small refactor on the userspace side without much
> > value. (I realize this has already been discussed a bit on the
> > previous version.)
> 
> I don't see much value in having userspace decode this value (again) after the
> kernel did it already and can easily provide the required information without
> making userspace commit to some encoding in the hardware (even though I do agree
> that it is unlikely).
> 
> OTH, the way chip IDs are derived has changed over the years (BOOT_0 / BOOT_42
> with different register layouts), and I'd rather not have userspace commit to
> any particular encoding when the kernel already provides the decoded
> information.
> 
> Regarding the refactor in mesa, the Nova uAPI won't follow nouveau anyway, so I
> don't want to limit ourselfs here.

I'm not particularly wedded to either approach but I think the approach is
either:

1) Keep the chip_id opaque, user-space looks up arch/implementation/etc. from a
   lookup table as required.

2) Keep the current scheme of just exposing the chip_id and letting user-space
   decode it assuming the register layout won't change.

In either case user-space needs to figure out arch/implementation/etc.

For (1) the kernel should not be responsible for decoding arch because if you're
assuming the register layout can change arbitrarily then the it can't reliably
figure out the arch anyway. For example if someone plugs a shiny new card with
a different chip_id register layout into a machine running an older kernel they
could get an incorrect arch which would be confusing. Users would get upset if
for example ShinyNewCard got reported as being Turing say.

So I think it makes sense to keep this decoding in user-space regardless of
whether that's exposed via documented opaque chip IDs and lookup tables for
arch/implementation or by a commitment to keep the chip ID register layout the
same.

Either of 1 or 2 seems fine to me.

 - Alistair

Re: [PATCH v4 4/7] drm: nova: Add a GPU info ioctl

[Alistair Popple]

On 2026-08-25 at 05:10 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> On Fri Aug 21, 2026 at 7:10 AM CEST, Alistair Popple wrote:
> > On 2026-08-18 at 06:18 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> >> On Tue Aug 11, 2026 at 7:06 AM CEST, Alistair Popple wrote:
> >> > diff --git a/include/uapi/drm/nova_drm.h b/include/uapi/drm/nova_drm.h
> >> > index ea7665383644..2604e4d2698b 100644
> >> > --- a/include/uapi/drm/nova_drm.h
> >> > +++ b/include/uapi/drm/nova_drm.h
> >> > @@ -118,9 +118,34 @@ struct drm_nova_gem_info {
> >> >  	__u64 size;
> >> >  };
> >> >  
> >> > +/**
> >> > + * struct drm_nova_gpu_info - query DRM GPU info.
> >> > + */
> >> > +struct drm_nova_gpu_info {
> >> > +	/**
> >> > +	 * @size: The amount of space allocated by userspace for this structure.
> >> > +	 * The kernel will return the amount of data it did/could actually write.
> >> > +	 * User space can use this to determine how much of the struct is valid
> >> > +	 * when running against an older kernel.
> >> > +	 */
> >> > +	__u64 size;
> >> > +
> >> > +	/**
> >> > +	 * @chipid: GPU chip identifier. See &enum drm_nova_chipid for currently
> >> > +	 * known chip identifiers.
> >> > +	 */
> >> > +	__u32 chipid;
> 
> I think we now also want to add a field for the architecture now that chipid is
> considered opaque.

I don't think so - see my response to patch 3 but I think the architecture
decoding needs to stay in user-space.

> >> > +
> >> > +	/**
> >> > +	 * @pad: 32 bit padding, must be 0.
> >> > +	 */
> >> > +	__u32 pad;
> >> > +};
> >> 
> >> I think we should add the indirection we discussed in [1], i.e. have an
> >> indirection via
> >> 
> >> 	struct drm_nova_info {
> >> 		__u32 id;
> >> 		__u32 size;
> >> 		__u64 info;
> >> 		/* Revserved fields, just in case? */
> >> 	};
> >> 
> >> so we can easily add new info structures, or extend an existing one with a v2
> >> without having to create new ioctls for this purpose.
> >
> > Sorry, I should have called this difference out more explicitly.
> >
> > Basically I ended up doing it this way because it didn't make much sense to me
> > putting an ioctl interface within an ioctl interface when DRM ioctl handling
> > can already deal with matching numbers and truncating/extending the struct as
> > required. It just leads to more code comparing ID's, etc and I'm not really sure
> > what the advantage is. Are we concerned about running out of ioctls if we have
> > to add other types of info struct?
> >
> > Doing this as top-level ioctl makes the strace decoders simpler and means we can
> > just rely on the existing DRM ioctl handling to get everything right rather than
> > duplicating that in nova-drm. Or is there some other advantage to [1] that I've
> > missed that isn't solved here?
> 
> I don't think we are really concerned about running out of ioctls, but it seems
> cleaner and more self-contained than having N ioctls for different info structs
> and in the worst case having v2...vN info ioctls.

But isn't v2...vN info ioctls dealt with in the usual way by extending the
existing struct and bumping the size? That seems like a pretty clean and
self-contained API to me.

> It also allows us to define a new info type struct whenever we think something
> is a new logical info group. Making it per ioctl will always raise the question
> of "do we really need a new ioctl for this, can't we just fit it in X", which
> over time tends to get messy.

Doesn't that question also apply to adding GETPARAM N+1 though? If we're not
worried about running out of top-level ioctls I don't understand why they
are considered special enough to warrant the extra complexity of creating and
decoding a hiearchy of sub-ioctls.

> I think eventually we will have a bunch of different info categories. OpenRM
> seems to have quite some as well (not too many categories, but with lots of
> fields), Xe and amdgpu have even more categories.

Sure, we could just reserve a block of top-level ioctls for info though if we
really cared about them being grouped together numerically. I'm not sure why
keeping them group numerically really matters though, it's nice to have but I
don't think it warrants any extra code.

But perhaps seeing an actual user of this API would be helpful for this
discussion, I will aim to do a pull request to drm-test this week to
demonstrate.

 - Alistair

> > Thanks for looking.
> >
> >  - Alistair
> >
> >> 
> >> [1] https://lore.kernel.org/nova-gpu/DKC6T1DQX2L3.HTHPB2L167TC@kernel.org/
> >> 
> >> >  #define DRM_NOVA_GETPARAM		0x00
> >> >  #define DRM_NOVA_GEM_CREATE		0x01
> >> >  #define DRM_NOVA_GEM_INFO		0x02
> >> > +#define DRM_NOVA_GPU_INFO		0x03
> >> >  
> >> >  /* Note: this is an enum so that it can be resolved by Rust bindgen. */
> >> >  enum {
> >> > @@ -130,6 +155,8 @@ enum {
> >> >  						   struct drm_nova_gem_create),
> >> >  	DRM_IOCTL_NOVA_GEM_INFO		= DRM_IOWR(DRM_COMMAND_BASE + DRM_NOVA_GEM_INFO,
> >> >  						   struct drm_nova_gem_info),
> >> > +	DRM_IOCTL_NOVA_GPU_INFO		= DRM_IOWR(DRM_COMMAND_BASE + DRM_NOVA_GPU_INFO,
> >> > +						   struct drm_nova_gpu_info),
> >> >  };
> >> >  
> >> >  #if defined(__cplusplus)
> >> > -- 
> >> > 2.54.0
> >> 
> 

Re: [PATCH v4 3/7] drm: nova: Add chipid enum to nova-drm UAPI

[Alistair Popple]

On 2026-08-25 at 17:13 +1000, Alistair Popple <apopple@nvidia.com> wrote...
> On 2026-08-25 at 05:24 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> > On Mon Aug 24, 2026 at 4:49 PM CEST, M Henning wrote:
> > > On Tue, Aug 11, 2026 at 1:12 AM Alistair Popple <apopple@nvidia.com> wrote:
> > >> +/*
> > >> + * Opaque chipids. These may be used to determine what chip a particular GPU is
> > >> + * based on the identifier but the values themselves should not be assumed to
> > >> + * carry any particular meaning.
> > >> + */
> > >
> > > You say this is opaque, but the userspace MR you posted already treats
> > > the values as non-opaque in eg. sm_for_chipset.
> > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43352/diffs?commit_id=945a8e7c51939577526974b342c8dc6bafc3372f
> > > So, I guess my question is, is is opaque or not?
> > 
> > The PR is outdated and goes back to the first version of this patch series;
> > what's written here is correct.
> 
> Right - I was holding off on updating the PR until we'd settled on the UAPI
> here.
> 
> > > I don't see much of a reason to make it opaque since the chipset has
> > > had the same structure on the hardware level for 30 years, so I don't
> > > expect it to change too often. Truly treating this as opaque would
> > > likely require a small refactor on the userspace side without much
> > > value. (I realize this has already been discussed a bit on the
> > > previous version.)
> > 
> > I don't see much value in having userspace decode this value (again) after the
> > kernel did it already and can easily provide the required information without
> > making userspace commit to some encoding in the hardware (even though I do agree
> > that it is unlikely).

Userspace has to commit to some kind of encoding about HW though. If we're going
to assume everything and anything about HW can change there's also no reason to
assume HW would continue using a chip architecture and a chip implementation as
having any meaning at all.

> > OTH, the way chip IDs are derived has changed over the years (BOOT_0 / BOOT_42
> > with different register layouts), and I'd rather not have userspace commit to
> > any particular encoding when the kernel already provides the decoded
> > information.
> > 
> > Regarding the refactor in mesa, the Nova uAPI won't follow nouveau anyway, so I
> > don't want to limit ourselfs here.

On the other hand we don't need to ignore the lessons of Nouveau either and try
and refactor everything - I agree there are plenty of UAPI choices that should
and will be different and we shouldn't limit ourselves - but if an interface has
been working well for 30 years and hasn't been causing anyone any issues then
perhaps we should just stick with it for Nova as well?

> 
> I'm not particularly wedded to either approach but I think the approach is
> either:
> 
> 1) Keep the chip_id opaque, user-space looks up arch/implementation/etc. from a
>    lookup table as required.
> 
> 2) Keep the current scheme of just exposing the chip_id and letting user-space
>    decode it assuming the register layout won't change.
> 
> In either case user-space needs to figure out arch/implementation/etc.
> 
> For (1) the kernel should not be responsible for decoding arch because if you're
> assuming the register layout can change arbitrarily then the it can't reliably
> figure out the arch anyway. For example if someone plugs a shiny new card with
> a different chip_id register layout into a machine running an older kernel they
> could get an incorrect arch which would be confusing. Users would get upset if
> for example ShinyNewCard got reported as being Turing say.

Thinking about this some more I think I conflated the architecutre and
implementation a bit. A new arch would _probably_ require other driver changes
anyway, so perhaps my example is a little contrived. The point I was trying to
make was that requiring backporting of kernel patches and forced driver upgrades
just to get a new impl (or maybe arch) decoding would be unfortunate.

We may well never get to the point of being able to have a (slightly) older
driver support a new impl, but I still think it would be best not to bake that
requirement in.

> So I think it makes sense to keep this decoding in user-space regardless of
> whether that's exposed via documented opaque chip IDs and lookup tables for
> arch/implementation or by a commitment to keep the chip ID register layout the
> same.
> 
> Either of 1 or 2 seems fine to me.
>  - Alistair