From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "John Hubbard" <jhubbard@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>,
"Shashank Sharma" <shashanks@nvidia.com>,
"Zhi Wang" <zhiw@nvidia.com>, "David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
rust-for-linux@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v10 24/28] gpu: nova-core: Hopper/Blackwell: larger non-WPR heap
Date: Mon, 20 Apr 2026 11:52:38 +0900 [thread overview]
Message-ID: <DHXN4H7HAQL6.2H006OV47SJZV@nvidia.com> (raw)
In-Reply-To: <20260411024953.473149-25-jhubbard@nvidia.com>
On Sat Apr 11, 2026 at 11:49 AM JST, John Hubbard wrote:
> Add dedicated FB HALs for Hopper (GH100) and Blackwell (GB100) with
> architecture-specific non-WPR heap sizes. Hopper uses 2 MiB, Blackwell
> uses 2 MiB + 128 KiB. These are needed for the larger reserved memory
> regions that Hopper/Blackwell GPUs require.
>
> Also adds the non_wpr_heap_size() method to the FbHal trait, and
> the total_reserved_size field to FbLayout.
>
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Let's move this patch earlier in the series, e.g. right after "new
location for PCI config mirror".
This will keep all the architecture setup/non-messaging patches
together, and keep the more complex message queue ones at the end,
forming a more logical flow and letting us merge these ones first
(hopefully reducing the series to just the FSP messaging patches soon).
> ---
> drivers/gpu/nova-core/fb.rs | 14 +++++++---
> drivers/gpu/nova-core/fb/hal.rs | 19 +++++++++-----
> drivers/gpu/nova-core/fb/hal/ga102.rs | 2 +-
> drivers/gpu/nova-core/fb/hal/gb100.rs | 38 +++++++++++++++++++++++++++
> drivers/gpu/nova-core/fb/hal/gh100.rs | 38 +++++++++++++++++++++++++++
> 5 files changed, 101 insertions(+), 10 deletions(-)
> create mode 100644 drivers/gpu/nova-core/fb/hal/gb100.rs
> create mode 100644 drivers/gpu/nova-core/fb/hal/gh100.rs
>
> diff --git a/drivers/gpu/nova-core/fb.rs b/drivers/gpu/nova-core/fb.rs
> index c2005e4b4177..756ff283a908 100644
> --- a/drivers/gpu/nova-core/fb.rs
> +++ b/drivers/gpu/nova-core/fb.rs
> @@ -103,6 +103,15 @@ pub(crate) fn unregister(&self, bar: &Bar0) {
> }
> }
>
> +/// Calculate non-WPR heap size based on chipset architecture.
> +/// This matches the logic used in FSP for consistency.
> +pub(crate) fn calc_non_wpr_heap_size(chipset: Chipset) -> u64 {
> + hal::fb_hal(chipset)
> + .non_wpr_heap_size()
> + .map(u64::from)
> + .unwrap_or(u64::SZ_1M)
> +}
This method is only ever called in a single place (which already has the
HAL at hand), let's just inline it. The name is misleading as it doesn't
calculate anything, it just returns a fixed per-chipset value. The
comment is also not particularly informative so we won't lose much by
dropping it.
> +
> pub(crate) struct FbRange(Range<u64>);
>
> impl FbRange {
> @@ -262,9 +271,8 @@ pub(crate) fn new(chipset: Chipset, bar: &Bar0, gsp_fw: &GspFirmware) -> Result<
> };
>
> let heap = {
> - const HEAP_SIZE: u64 = u64::SZ_1M;
> -
> - FbRange(wpr2.start - HEAP_SIZE..wpr2.start)
> + let heap_size = calc_non_wpr_heap_size(chipset);
> + FbRange(wpr2.start - heap_size..wpr2.start)
> };
>
> Ok(Self {
> diff --git a/drivers/gpu/nova-core/fb/hal.rs b/drivers/gpu/nova-core/fb/hal.rs
> index 3b3bad0feed0..478f80d640c1 100644
> --- a/drivers/gpu/nova-core/fb/hal.rs
> +++ b/drivers/gpu/nova-core/fb/hal.rs
> @@ -12,6 +12,8 @@
>
> mod ga100;
> mod ga102;
> +mod gb100;
> +mod gh100;
> mod tu102;
>
> pub(crate) trait FbHal {
> @@ -28,17 +30,22 @@ pub(crate) trait FbHal {
>
> /// Returns the VRAM size, in bytes.
> fn vidmem_size(&self, bar: &Bar0) -> u64;
> +
> + /// Returns the non-WPR heap size for GPUs that need large reserved memory.
> + ///
> + /// Returns `None` for GPUs that don't need extra reserved memory.
> + fn non_wpr_heap_size(&self) -> Option<u32> {
> + None
> + }
This HAL method is bizarre.
Why return an `Option` when `0` expresses "I don't need extra memory"
just as well?
Then there's the user of this HAL defaulting to `SZ_1M` if it returned
`None`, which was the default value for `heap`. But if it returns
something else than `None`, then we just use that value for `heap`,
without adding `SZ_1M`... So what it appears to do is that it returns
the total amount of heap, except when it returns `None` in which case
the heap value should be `SZ_1M`?
If that's the case, then why not just have a `heap_size` that simply
returns the amount of heap needed (without any `Option`), and just use
that without further complications?
Please confirm whether the values returned in the HAL are actually total
heap size, and if they are, let's generalize the HAL to all GPU
generations.
> }
>
> /// Returns the HAL corresponding to `chipset`.
> -pub(super) fn fb_hal(chipset: Chipset) -> &'static dyn FbHal {
> +pub(crate) fn fb_hal(chipset: Chipset) -> &'static dyn FbHal {
The visibility of this method doesn't need to be changed.
> match chipset.arch() {
> Architecture::Turing => tu102::TU102_HAL,
> Architecture::Ampere if chipset == Chipset::GA100 => ga100::GA100_HAL,
> - Architecture::Ampere => ga102::GA102_HAL,
> - Architecture::Ada
> - | Architecture::Hopper
> - | Architecture::BlackwellGB10x
> - | Architecture::BlackwellGB20x => ga102::GA102_HAL,
> + Architecture::Ampere | Architecture::Ada => ga102::GA102_HAL,
> + Architecture::Hopper => gh100::GH100_HAL,
> + Architecture::BlackwellGB10x | Architecture::BlackwellGB20x => gb100::GB100_HAL,
> }
> }
> diff --git a/drivers/gpu/nova-core/fb/hal/ga102.rs b/drivers/gpu/nova-core/fb/hal/ga102.rs
> index 4b9f0f74d0e7..79c5a44f6a29 100644
> --- a/drivers/gpu/nova-core/fb/hal/ga102.rs
> +++ b/drivers/gpu/nova-core/fb/hal/ga102.rs
> @@ -11,7 +11,7 @@
> regs, //
> };
>
> -fn vidmem_size_ga102(bar: &Bar0) -> u64 {
> +pub(super) fn vidmem_size_ga102(bar: &Bar0) -> u64 {
> bar.read(regs::NV_USABLE_FB_SIZE_IN_MB).usable_fb_size()
> }
>
> diff --git a/drivers/gpu/nova-core/fb/hal/gb100.rs b/drivers/gpu/nova-core/fb/hal/gb100.rs
> new file mode 100644
> index 000000000000..bead99a6ca76
> --- /dev/null
> +++ b/drivers/gpu/nova-core/fb/hal/gb100.rs
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +use kernel::prelude::*;
> +
> +use crate::{
> + driver::Bar0,
> + fb::hal::FbHal, //
> +};
> +
> +struct Gb100;
> +
> +impl FbHal for Gb100 {
> + fn read_sysmem_flush_page(&self, bar: &Bar0) -> u64 {
> + super::ga100::read_sysmem_flush_page_ga100(bar)
> + }
> +
> + fn write_sysmem_flush_page(&self, bar: &Bar0, addr: u64) -> Result {
> + super::ga100::write_sysmem_flush_page_ga100(bar, addr);
> +
> + Ok(())
> + }
> +
> + fn supports_display(&self, bar: &Bar0) -> bool {
> + super::ga100::display_enabled_ga100(bar)
> + }
> +
> + fn vidmem_size(&self, bar: &Bar0) -> u64 {
> + super::ga102::vidmem_size_ga102(bar)
> + }
> +
> + fn non_wpr_heap_size(&self) -> Option<u32> {
> + // 2 MiB + 128 KiB non-WPR heap for Blackwell (see Open RM: kgspCalculateFbLayout_GB100).
> + Some(0x220000)
I could not find any function named `kgspCalculateFbLayout_GB100` in
OpenRM. There is one for GH100, but not for GB100. Also this method
computes the whole layout, the relevant one would be
`kgspGetNonWprHeapSize`.
Also I know this is a bit overkill, but let's make this a module-level
constant so other HALs can refer to it if needed.
> + }
> +}
> +
> +const GB100: Gb100 = Gb100;
> +pub(super) const GB100_HAL: &dyn FbHal = &GB100;
> diff --git a/drivers/gpu/nova-core/fb/hal/gh100.rs b/drivers/gpu/nova-core/fb/hal/gh100.rs
> new file mode 100644
> index 000000000000..32d7414e6243
> --- /dev/null
> +++ b/drivers/gpu/nova-core/fb/hal/gh100.rs
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +use kernel::prelude::*;
> +
> +use crate::{
> + driver::Bar0,
> + fb::hal::FbHal, //
> +};
> +
> +struct Gh100;
> +
> +impl FbHal for Gh100 {
> + fn read_sysmem_flush_page(&self, bar: &Bar0) -> u64 {
> + super::ga100::read_sysmem_flush_page_ga100(bar)
> + }
> +
> + fn write_sysmem_flush_page(&self, bar: &Bar0, addr: u64) -> Result {
> + super::ga100::write_sysmem_flush_page_ga100(bar, addr);
> +
> + Ok(())
> + }
> +
> + fn supports_display(&self, bar: &Bar0) -> bool {
> + super::ga100::display_enabled_ga100(bar)
> + }
> +
> + fn vidmem_size(&self, bar: &Bar0) -> u64 {
> + super::ga102::vidmem_size_ga102(bar)
> + }
> +
> + fn non_wpr_heap_size(&self) -> Option<u32> {
> + // 2 MiB non-WPR heap for Hopper (see Open RM: kgspCalculateFbLayout_GH100).
Here also let's remove the reference to `kgspCalculateFbLayout_GH100` -
it does exist as of 570.144, but has been removed in `main`.
`kgspGetNonWprHeapSize` is a more accurate reference if we need one.
next prev parent reply other threads:[~2026-04-20 2:52 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-11 2:49 [PATCH v10 00/28] gpu: nova-core: firmware: Hopper/Blackwell support John Hubbard
2026-04-11 2:49 ` [PATCH v10 01/28] gpu: nova-core: factor .fwsignature* selection into a new find_gsp_sigs_section() John Hubbard
2026-04-11 2:49 ` [PATCH v10 02/28] gpu: nova-core: use GPU Architecture to simplify HAL selections John Hubbard
2026-04-11 2:49 ` [PATCH v10 03/28] gpu: nova-core: Hopper/Blackwell: basic GPU identification John Hubbard
2026-04-11 3:58 ` Timur Tabi
2026-04-13 21:08 ` John Hubbard
2026-04-13 21:21 ` Timur Tabi
2026-04-13 21:29 ` John Hubbard
2026-04-17 7:27 ` Alexandre Courbot
2026-04-17 7:49 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 04/28] gpu: nova-core: add Copy/Clone to Spec and Revision John Hubbard
2026-04-11 2:49 ` [PATCH v10 05/28] gpu: nova-core: set DMA mask width based on GPU architecture John Hubbard
2026-04-11 2:49 ` [PATCH v10 06/28] gpu: nova-core: move GFW boot wait into a GPU HAL John Hubbard
2026-04-11 2:49 ` [PATCH v10 07/28] gpu: nova-core: Hopper/Blackwell: skip GFW boot waiting John Hubbard
2026-04-11 2:49 ` [PATCH v10 08/28] gpu: nova-core: Blackwell: calculate reserved FB heap size John Hubbard
2026-04-17 14:23 ` Alexandre Courbot
2026-04-18 1:42 ` John Hubbard
2026-04-11 2:49 ` [PATCH v10 09/28] gpu: nova-core: Hopper/Blackwell: new location for PCI config mirror John Hubbard
2026-04-17 14:23 ` Alexandre Courbot
2026-04-18 1:46 ` John Hubbard
2026-04-18 1:54 ` John Hubbard
2026-04-20 3:10 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 10/28] gpu: nova-core: refactor SEC2 booter loading into BooterFirmware::run() John Hubbard
2026-04-11 2:49 ` [PATCH v10 11/28] gpu: nova-core: Hopper/Blackwell: integrate FSP boot path into boot() John Hubbard
2026-04-17 14:24 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 12/28] gpu: nova-core: don't assume 64-bit firmware images John Hubbard
2026-04-11 2:49 ` [PATCH v10 13/28] gpu: nova-core: add support for 32-bit " John Hubbard
2026-04-11 2:49 ` [PATCH v10 14/28] gpu: nova-core: add auto-detection of 32-bit, 64-bit " John Hubbard
2026-04-11 2:49 ` [PATCH v10 15/28] gpu: nova-core: Hopper/Blackwell: add FSP falcon engine stub John Hubbard
2026-04-11 2:49 ` [PATCH v10 16/28] gpu: nova-core: Hopper/Blackwell: add FMC firmware image, in support of FSP John Hubbard
2026-04-11 2:49 ` [PATCH v10 17/28] gpu: nova-core: Hopper/Blackwell: add FSP secure boot completion waiting John Hubbard
2026-04-17 14:24 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 18/28] gpu: nova-core: Hopper/Blackwell: add FMC signature extraction John Hubbard
2026-04-17 14:24 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 19/28] gpu: nova-core: Hopper/Blackwell: add FSP falcon EMEM operations John Hubbard
2026-04-11 2:49 ` [PATCH v10 20/28] gpu: nova-core: Hopper/Blackwell: add FSP message infrastructure John Hubbard
2026-04-11 2:49 ` [PATCH v10 21/28] gpu: nova-core: add MCTP/NVDM protocol types for firmware communication John Hubbard
2026-04-11 2:49 ` [PATCH v10 22/28] gpu: nova-core: Hopper/Blackwell: add FSP send/receive messaging John Hubbard
2026-04-11 2:49 ` [PATCH v10 23/28] gpu: nova-core: Hopper/Blackwell: add FspCotVersion type John Hubbard
2026-04-11 2:49 ` [PATCH v10 24/28] gpu: nova-core: Hopper/Blackwell: larger non-WPR heap John Hubbard
2026-04-20 2:52 ` Alexandre Courbot [this message]
2026-04-11 2:49 ` [PATCH v10 25/28] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot John Hubbard
2026-04-11 2:49 ` [PATCH v10 26/28] gpu: nova-core: Blackwell: use correct sysmem flush registers John Hubbard
2026-04-11 2:49 ` [PATCH v10 27/28] gpu: nova-core: Hopper/Blackwell: larger WPR2 (GSP) heap John Hubbard
2026-04-20 7:02 ` Alexandre Courbot
2026-04-11 2:49 ` [PATCH v10 28/28] gpu: nova-core: Hopper/Blackwell: add GSP lockdown release polling John Hubbard
2026-04-17 14:34 ` [PATCH v10 00/28] gpu: nova-core: firmware: Hopper/Blackwell support Alexandre Courbot
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=DHXN4H7HAQL6.2H006OV47SJZV@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=shashanks@nvidia.com \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=zhiw@nvidia.com \
/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