linux-kernel - Re: [PATCH v2 8/8] gpu: nova-core: compute layout of more framebuffer regions required for GSP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e091c6c1-98f8-4876-b2f1-c928da7aa7eb@nvidia.com>
Date: Fri, 29 Aug 2025 16:30:58 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Alexandre Courbot <acourbot@...dia.com>, Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>,
 Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>,
 David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>
Cc: Alistair Popple <apopple@...dia.com>,
 Joel Fernandes <joelagnelf@...dia.com>, Timur Tabi <ttabi@...dia.com>,
 rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
 nouveau@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2 8/8] gpu: nova-core: compute layout of more framebuffer
 regions required for GSP

On 8/25/25 9:07 PM, Alexandre Courbot wrote:
> diff --git a/drivers/gpu/nova-core/fb.rs b/drivers/gpu/nova-core/fb.rs
> index b0e860498b883815b3861b8717f8ee1832d25440..a3eb063f86b3a06a7ad01e684919115abf5e28da 100644
...
>          let fb = {
> @@ -138,10 +202,54 @@ pub(crate) fn new(chipset: Chipset, bar: &Bar0) -> Result<Self> {
>              frts_base..frts_base + FRTS_SIZE
>          };
>  
> +        let boot = {

A few lines earlier, not shown in these diffs because it's not part of this patch,
there is a closely related TODO item:

            // TODO[NUMM]: replace with `align_down` once it lands.
            let frts_base = (vga_workspace.start & !(FRTS_DOWN_ALIGN - 1)) - FRTS_SIZE;

...which I think could be optionally fixed now, and added to this patch.

Or it could be done later, in a different patch, but it seems convenient
to merge it in as long as we're here, and using .align_down() in this patch.

...
> diff --git a/drivers/gpu/nova-core/nvfw.rs b/drivers/gpu/nova-core/nvfw.rs
> index 7c5baccc34a2387c30e51f93d3ae039b14b6b83a..11a63c3710b1aa1eec78359c15c101bdf2ad99c8 100644
> --- a/drivers/gpu/nova-core/nvfw.rs
> +++ b/drivers/gpu/nova-core/nvfw.rs
> @@ -1,3 +1,42 @@
>  // SPDX-License-Identifier: GPL-2.0
>  
>  mod r570_144;
> +
> +use core::ops::Range;
> +
> +use kernel::sizes::SZ_1M;
> +
> +/// Heap memory requirements and constraints for a given version of the GSP LIBOS.
> +pub(crate) struct LibosParams {
> +    /// The base amount of heap required by the GSP operating system, in bytes.
> +    pub(crate) carveout_size: u64,
> +    /// The minimum and maximum sizes allowed for the GSP FW heap, in bytes.
> +    pub(crate) allowed_heap_size: Range<u64>,
> +}
> +
> +/// Version 2 of the GSP LIBOS (Turing and GA100)
> +pub(crate) const LIBOS2_PARAMS: LibosParams = LibosParams {
> +    carveout_size: r570_144::GSP_FW_HEAP_PARAM_OS_SIZE_LIBOS2 as u64,
> +    allowed_heap_size: r570_144::GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS2_MIN_MB as u64 * SZ_1M as u64
> +        ..r570_144::GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS2_MAX_MB as u64 * SZ_1M as u64,

We only support one version of the firmware. And in the coming months,
that one version will have a different version number.

Given those constraints, we should simply remove most (all?) of the "r570_144::"
namespace qualifiers in the code, starting here.

That way, we get:

a) A small diff, instead of a huge one, when we update to a new firmware
   version.

b) Shorter, cleaner symbols everywhere: GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS2_MAX_MB
   instead of r570_144::GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS2_MAX_MB, for example.

> +};
> +
> +/// Version 3 of the GSP LIBOS (GA102+)
> +pub(crate) const LIBOS3_PARAMS: LibosParams = LibosParams {
> +    carveout_size: r570_144::GSP_FW_HEAP_PARAM_OS_SIZE_LIBOS3_BAREMETAL as u64,
> +    allowed_heap_size: r570_144::GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS3_BAREMETAL_MIN_MB as u64
> +        * SZ_1M as u64
> +        ..r570_144::GSP_FW_HEAP_SIZE_OVERRIDE_LIBOS3_BAREMETAL_MAX_MB as u64 * SZ_1M as u64,
> +};
> +
> +/// Amount of GSP-RM heap memory used during GSP-RM boot and initialization (up to and including
> +/// the first client subdevice allocation) on Turing/Ampere/Ada.
> +pub(crate) use r570_144::GSP_FW_HEAP_PARAM_BASE_RM_SIZE_TU10X;
> +/// WPR heap usage of a single client channel allocation.
> +pub(crate) use r570_144::GSP_FW_HEAP_PARAM_CLIENT_ALLOC_SIZE;
> +/// Amount of extra WPR heap to reserve per GB of framebuffer memory, in bytes.
> +pub(crate) use r570_144::GSP_FW_HEAP_PARAM_SIZE_PER_GB_FB;
> +
> +/// Structure passed to the GSP bootloader, containing the framebuffer layout as well as the DMA
> +/// addresses of the GSP bootloader and firmware.
> +pub(crate) use r570_144::GspFwWprMeta;

thanks,
-- 
John Hubbard