Rust for Linux List
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: Danilo Krummrich <dakr@kernel.org>
Cc: nova-gpu <nova-gpu@lists.linux.dev>,
	 M Henning <mhenning@darkrefraction.com>,
	Alice Ryhl <aliceryhl@google.com>,
	 David Airlie <airlied@gmail.com>,
	Alexandre Courbot <acourbot@nvidia.com>,
	 Benno Lossin <lossin@kernel.org>, Gary Guo <gary@garyguo.net>,
	 Eliot Courtney <ecourtney@nvidia.com>,
	John Hubbard <jhubbard@nvidia.com>,
	linux-kernel@vger.kernel.org,  dri-devel@lists.freedesktop.org,
	rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v5 05/11] drm: nova: Add an info ioctl
Date: Tue, 1 Sep 2026 13:47:31 +1000	[thread overview]
Message-ID: <apZCTUYiN5FHCkCm@nvdebian.thelocal> (raw)
In-Reply-To: <DL373JA1ZANX.21L51RTEUQ2UG@kernel.org>

On 2026-09-01 at 00:23 +1000, Danilo Krummrich <dakr@kernel.org> wrote...
> On Fri Aug 28, 2026 at 5:35 AM CEST, Alistair Popple wrote:
> > +/// GPU information returned to userspace.
> > +///
> > +/// # Invariants
> > +///
> > +/// - The layout of this type is identical to `struct drm_nova_gpu_info`.
> > +/// - All bytes in the value are initialized.
> 
> I don't think we need those invariants. The first one is covered by
> #[repr(transparent)] and the second invariant is trivally satisfied by the fact
> that we create a value of that type.

Ok.

> Maybe you meant to say that we explicitly initialized everything despite
> uapi::drm_nova_gpu_info being FromBytes (i.e. no "random" values)? But I think
> even that wouldn't need an invariant.

Yep, basically trying to justify why As/FromBytes is safe but if the safety
comments for these implementations on their own are adequate I will just use
those and remove this.

> > +#[repr(transparent)]
> > +struct GpuInfo(uapi::drm_nova_gpu_info);
> > +
> > +impl GpuInfo {
> > +    fn new(reg_data: &DrmRegData<'_>) -> Self {
> > +        Self(uapi::drm_nova_gpu_info {
> > +            architecture: reg_data.api.architecture(),
> > +            implementation: reg_data.api.implementation(),
> > +        })
> > +    }
> > +}
> > +
> > +// SAFETY: `GpuInfo` has no implicit padding, kernel pointers, or interior
> > +// mutability, and all of its fields are initialized before it is written to
> > +// userspace.
> > +unsafe impl AsBytes for GpuInfo {}
> > +
> > +fn write_info<T: AsBytes>(info: &mut uapi::drm_nova_info, value: &T) -> Result {
> 
> We could take T by value I guess? We don't need it anymore after it has been
> written to the user buffer.

Makes sense.

> > +    let mut writer =
> > +        UserSlice::new(UserPtr::from_addr(info.data as usize), info.size as usize).writer();
> > +
> > +    info.size = writer.write_truncated(value)? as u32;
> > +
> > +    Ok(())
> > +}
> > +
> >  impl drm::file::DriverFile for File {
> >      type Driver = NovaDriver;
> >  
> > @@ -78,4 +112,27 @@ pub(crate) fn gem_info(
> >  
> >          Ok(0)
> >      }
> > +
> > +    /// IOCTL: info: Query device information.
> > +    pub(crate) fn info(
> > +        _dev: &NovaDevice<Registered>,
> > +        reg_data: &DrmRegData<'_>,
> > +        info: &mut uapi::drm_nova_info,
> > +        _file: &drm::File<File>,
> > +    ) -> Result<u32> {
> > +        if info.data == 0 {
> > +            info.size = match info.id {
> > +                uapi::DRM_NOVA_INFO_GPU => size_of::<GpuInfo>() as u32,
> > +                _ => return Err(EINVAL),
> > +            };
> > +            return Ok(0);
> > +        }
> 
> I think this check can go into write_info(), so we don't have to repeat this for
> every info. I.e. we can just add
> 
> 	if info.data == 0 {
> 	    info.size = size_of::<T>() as u32;
> 	    return Ok(());
> 	}
> 
> at the beginning of write_info(). It may construct the value even if
> info.data == 0, but I don't think we care. :)

Heh. That was why I did it this way, in case obtaining the info was expensive
for some value of "expensive". But info should mostly be cached (ie. cheap) and
I don't mind keeping things simple :)

> 
> > +
> > +        match info.id {
> > +            uapi::DRM_NOVA_INFO_GPU => write_info(info, &GpuInfo::new(reg_data))?,
> > +            _ => return Err(EINVAL),
> > +        }
> > +
> > +        Ok(0)
> > +    }
> >  }
> > diff --git a/drivers/gpu/nova-core/api.rs b/drivers/gpu/nova-core/api.rs
> > index 610cfc01111e..cff730a38c1d 100644
> > --- a/drivers/gpu/nova-core/api.rs
> > +++ b/drivers/gpu/nova-core/api.rs
> > @@ -12,11 +12,12 @@
> >      types::CovariantForLt, //
> >  };
> >  
> > -use crate::gpu::Gpu;
> > +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>>,
> >  }
> >  
> > @@ -26,4 +27,14 @@ impl NovaCoreApi<'_> {
> >      pub fn of(adev: &auxiliary::Device<Bound>) -> Result<Pin<&NovaCoreApi<'_>>> {
> >          adev.registration_data::<CovariantForLt!(NovaCoreApi<'_>)>()
> >      }
> > +
> > +    /// Returns the architecture identifier of this GPU.
> > +    pub fn architecture(&self) -> u32 {
> > +        self.gpu.spec.chipset.arch() as u32
> > +    }
> > +
> > +    /// Returns the implementation identifier of this GPU.
> > +    pub fn implementation(&self) -> u32 {
> > +        self.gpu.spec.chipset.implementation()
> > +    }
> 
> We should make the NovaCoreApi just provide an accessor for &Spec and make every
> subsequent method we need public. Otherwise we end up with endless forwarding
> methods. We can also add as_raw() methods to the specific types as needed.

Ok. This is where I don't have a good instinct for what we think should be an
accessor/forwarding method vs. where we should just expose the underlying data
structure and required methods to API users.

In the past it seems there's been some resistance to exposing nova-core or gsp
data structures like this which is why I added the forwarding methods. In future
we're going to have other data-structures that NovaCoreApi will need to access
so it would be good to understand what we should do here so we can keep things
somewhat consistent.

It seems pretty arbitrary to say expose self.gpu.spec externally
because of endless forwarding methods but to then require them for say
self.gpu.gsp_static_info. So maybe we can just have a NovaCoreApi method that
returns self.gpu directly instead of writing forwarding methods for each field
of self.gpu that we need to access? Access to genuinely internal nova-core
fields/methods can always be controlled through visibility modifiers.

 - Alistair

  reply	other threads:[~2026-09-01  3:47 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28  3:35 [PATCH v5 00/11] gpu: nova: Export parameters from nova-core to nova-drm Alistair Popple
2026-08-28  3:35 ` [PATCH v5 01/11] gpu: nova-core: Add public driver API to nova-core Alistair Popple
2026-08-31 20:08   ` Danilo Krummrich
2026-08-31 20:42     ` Gary Guo
2026-09-01  7:07       ` Alistair Popple
2026-09-01  7:14         ` Danilo Krummrich
2026-09-01  9:13           ` Alistair Popple
2026-09-01  9:21             ` Danilo Krummrich
2026-09-01 10:27       ` Danilo Krummrich
2026-09-01 11:35         ` Gary Guo
2026-09-01  3:53     ` Alistair Popple
2026-09-02  6:57     ` Alistair Popple
2026-09-02 19:30       ` Danilo Krummrich
2026-08-28  3:35 ` [PATCH v5 02/11] drm: nova: Add DRM registration data Alistair Popple
2026-08-28  3:35 ` [PATCH v5 03/11] drm: nova: Add GPU architecture enum to nova-drm UAPI Alistair Popple
2026-08-28  3:35 ` [PATCH v5 04/11] rust: uaccess: add UserSliceWriter::write_truncated() Alistair Popple
2026-08-28  3:35 ` [PATCH v5 05/11] drm: nova: Add an info ioctl Alistair Popple
2026-08-31  4:58   ` Alistair Popple
2026-08-31 14:23   ` Danilo Krummrich
2026-09-01  3:47     ` Alistair Popple [this message]
2026-09-01  4:50       ` Dave Airlie
2026-09-01  5:09         ` Alistair Popple
2026-09-01  7:29           ` Danilo Krummrich
2026-09-02  5:21             ` Alistair Popple
2026-09-02  7:05               ` Alistair Popple
2026-09-02 19:26                 ` Danilo Krummrich
2026-09-02 19:38                   ` Dave Airlie
2026-09-02 19:42                     ` Danilo Krummrich
2026-09-01  4:53   ` Dave Airlie
2026-09-01  5:24     ` Alistair Popple
2026-09-01 10:38   ` Danilo Krummrich
2026-09-01 17:01     ` Danilo Krummrich
2026-09-02  2:38       ` Alistair Popple
2026-09-02  9:40         ` Danilo Krummrich
2026-09-03  1:12           ` Alistair Popple
2026-09-03 10:42             ` Danilo Krummrich
2026-09-04  7:49               ` Alistair Popple
2026-09-04  9:34                 ` Danilo Krummrich
2026-09-04 11:13               ` Gary Guo
2026-09-04 12:08                 ` Danilo Krummrich
2026-08-28  3:35 ` [PATCH v5 06/11] drm: nova: Add usable VRAM size to GPU info Alistair Popple
2026-08-28  3:35 ` [PATCH v5 07/11] drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter Alistair Popple
2026-08-28  3:35 ` [PATCH v5 08/11] drm: nova: Expose a render node Alistair Popple
2026-08-28  3:35 ` [PATCH v5 09/11] drm: nova: Report GPU name in GPU info Alistair Popple
2026-08-31 14:33   ` Danilo Krummrich
2026-09-01  3:09     ` Alistair Popple
2026-08-28  3:35 ` [PATCH v5 10/11] drm: nova: Report GPU short " Alistair Popple
2026-08-31 14:41   ` Danilo Krummrich
2026-09-01  3:10     ` Alistair Popple
2026-08-28  3:35 ` [PATCH v5 11/11] drm: nova: Report GPU GID " Alistair Popple
2026-08-28  6:04 ` [PATCH v5 00/11] gpu: nova: Export parameters from nova-core to nova-drm Alistair Popple

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=apZCTUYiN5FHCkCm@nvdebian.thelocal \
    --to=apopple@nvidia.com \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ecourtney@nvidia.com \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=mhenning@darkrefraction.com \
    --cc=nova-gpu@lists.linux.dev \
    --cc=rust-for-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox