mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joel Fernandes <joelagnelf@nvidia.com>
To: John Hubbard <jhubbard@nvidia.com>, Danilo Krummrich <dakr@kernel.org>
Cc: "Alexandre Courbot" <acourbot@nvidia.com>,
	"Timur Tabi" <ttabi@nvidia.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	"Edwin Peer" <epeer@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>,
	nouveau@lists.freedesktop.org, rust-for-linux@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 23/31] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot
Date: Fri, 5 Dec 2025 12:15:29 -0500	[thread overview]
Message-ID: <dcd18bd8-cb7e-4c28-b4c6-95a201710270@nvidia.com> (raw)
In-Reply-To: <20251203055923.1247681-24-jhubbard@nvidia.com>

Hi John,

On 12/3/2025 12:59 AM, John Hubbard wrote:
> +    ///
> +    /// This version takes pre-extracted signatures and FMC image data.
> +    /// Used when signatures are extracted separately from the full ELF file.
> +    #[allow(clippy::too_many_arguments)]
> +    pub(crate) fn boot_gsp_fmc_with_signatures(
> +        dev: &device::Device<device::Bound>,
> +        bar: &crate::driver::Bar0,
> +        chipset: crate::gpu::Chipset,
> +        fmc_image_fw: &crate::dma::DmaObject, // Contains only the image section
> +        fmc_boot_params: &kernel::dma::CoherentAllocation<GspFmcBootParams>,
> +        total_reserved_size: u64,
> +        resume: bool,
> +        fsp_falcon: &crate::falcon::Falcon<crate::falcon::fsp::Fsp>,
> +        signatures: &FmcSignatures,
> +    ) -> Result<()> {
> +        dev_dbg!(dev, "Starting FSP boot sequence for {}\n", chipset);

I see lots of dev_dbg left as you also pointed. I guess you will remove these as
we discussed in the other thread.

> +
> +        // Build FSP Chain of Trust message
> +        let fmc_addr = fmc_image_fw.dma_handle(); // Now points to image data only
> +        let fmc_boot_params_addr = fmc_boot_params.dma_handle();
> +
> +        // frts_offset is relative to FB end: FRTS_location = FB_END - frts_offset
> +        let frts_offset = if !resume {
> +            let mut frts_reserved_size = if chipset.needs_large_reserved_mem() {
> +                0x220000 // heap_size_non_wpr for Hopper/Blackwell+

Can we please use constants for the magic numbers? Also with comment headers
clearly documenting the constants where they are defined.

> +            } else {
> +                total_reserved_size
> +            };
> +
> +            // Add PMU reserved size
> +            frts_reserved_size += u64::from(crate::fb::PMU_RESERVED_SIZE);
> +
> +            frts_reserved_size
> +                .align_up(Alignment::new::<0x200000>())
> +                .unwrap_or(frts_reserved_size)
> +        } else {
> +            0
> +        };
> +        let frts_size = if !resume { 0x100000 } else { 0 }; // 1MB FRTS size


Should use SZ_ constants, here and everywhere. Like SZ_1M etc [1].

[1] https://rust.docs.kernel.org/src/kernel/sizes.rs.html

> +
> +        // Build the FSP message
> +        let msg = KBox::new(
> +            FspMessage {
> +                mctp_header: (mctp::HEADER_SOM << 31)
> +                    | (mctp::HEADER_EOM << 30)
> +                    | (mctp::HEADER_SEID << 16)
> +                    | (mctp::HEADER_SEQ << 28),
> +
> +                nvdm_header: (mctp::MSG_TYPE_VENDOR_PCI)
> +                    | (mctp::VENDOR_ID_NV << 8)
> +                    | (mctp::NVDM_TYPE_COT << 24),
> +
> +                cot: NvdmPayloadCot {
> +                    version: FSP_COT_VERSION,
> +                    size: core::mem::size_of::<NvdmPayloadCot>() as u16,
> +                    gsp_fmc_sysmem_offset: fmc_addr,
> +                    frts_sysmem_offset: 0,
> +                    frts_sysmem_size: 0,
> +                    frts_vidmem_offset: frts_offset,
> +                    frts_vidmem_size: frts_size,
> +                    hash384: signatures.hash384,
> +                    public_key: signatures.public_key,
> +                    signature: signatures.signature,
> +                    gsp_boot_args_sysmem_offset: fmc_boot_params_addr,
> +                },
> +            },
> +            GFP_KERNEL,
> +        )?;
> +
> +        // Convert message to bytes for sending
> +        let msg_bytes = msg.as_bytes();
> +
> +        dev_dbg!(
> +            dev,
> +            "FSP COT Message:\n  size={} bytes\n  fmc_addr={:#x}\n  boot_params={:#x}\n  \
> +             frts_offset={:#x}\n  frts_size={:#x}\n",
> +            msg_bytes.len(),
> +            fmc_addr,
> +            fmc_boot_params_addr,
> +            frts_offset,
> +            frts_size
> +        );
> +
> +        // Send COT message to FSP and wait for response
> +        Self::send_sync_fsp(dev, bar, fsp_falcon, mctp::NVDM_TYPE_COT, msg_bytes)?;

This seems to diverge from the pattern we use in GSP `cmdq`. Can we keep it
consistent, like `send_sync_fsp<M>` ?

    pub(crate) fn send_command<M>(&mut self, bar: &Bar0, command: M) -> Result
    where
        M: CommandToGsp,

Alistair/Alex may have more design suggestions since they came up with this
pattern. Especially around safety (guarantees that the part of buffer being read
will not be modified by HW etc).

Over all, I feel we have 3 different mechanisms now (1 upstream, 2 in the
works). The GSP cmdq, RM control and then this one. It would be good to get some
consistency in the API designs for all these different mechanisms (and possibly
share any common code).

Thanks!

 - Joel





  reply	other threads:[~2025-12-05 17:15 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-03  5:58 [PATCH 00/31] gpu: nova-core: firmware: Hopper/Blackwell support John Hubbard
2025-12-03  5:58 ` [PATCH 01/31] gpu: nova-core: print FB sizes, along with ranges John Hubbard
2025-12-03 19:35   ` Timur Tabi
2025-12-04  7:27     ` John Hubbard
2026-01-13 13:28   ` Gary Guo
2026-01-13 13:42     ` Miguel Ojeda
2026-01-14  2:23     ` John Hubbard
2026-01-23  3:09       ` John Hubbard
2026-01-23 18:04         ` Gary Guo
2025-12-03  5:58 ` [PATCH 02/31] gpu: nova-core: add FbRange.len() and use it in boot.rs John Hubbard
2026-01-13 13:29   ` Gary Guo
2025-12-03  5:58 ` [PATCH 03/31] gpu: nova-core: Hopper/Blackwell: basic GPU identification John Hubbard
2025-12-03  5:58 ` [PATCH 04/31] nova-core: factor .fwsignature* selection into a new get_gsp_sigs_section() John Hubbard
2026-01-13 13:33   ` Gary Guo
2026-01-14  2:24     ` John Hubbard
2025-12-03  5:58 ` [PATCH 05/31] gpu: nova-core: use GPU Architecture to simplify HAL selections John Hubbard
2025-12-03 19:38   ` Timur Tabi
2025-12-04  7:28     ` John Hubbard
2025-12-03  5:58 ` [PATCH 06/31] gpu: nova-core: apply the one "use" item per line policy to commands.rs John Hubbard
2026-01-13 13:35   ` Gary Guo
2025-12-03  5:58 ` [PATCH 07/31] gpu: nova-core: set DMA mask width based on GPU architecture John Hubbard
2026-01-13 13:43   ` Gary Guo
2026-01-14  3:03     ` John Hubbard
2025-12-03  5:59 ` [PATCH 08/31] gpu: nova-core: move firmware image parsing code to firmware.rs John Hubbard
2026-01-13 13:44   ` Gary Guo
2025-12-03  5:59 ` [PATCH 09/31] gpu: nova-core: factor out a section_name_eq() function John Hubbard
2026-01-13 13:57   ` Gary Guo
2026-01-14  3:18     ` John Hubbard
2026-01-14 14:40       ` Gary Guo
2025-12-03  5:59 ` [PATCH 10/31] gpu: nova-core: don't assume 64-bit firmware images John Hubbard
2025-12-03  5:59 ` [PATCH 11/31] gpu: nova-core: add support for 32-bit " John Hubbard
2025-12-03  5:59 ` [PATCH 12/31] gpu: nova-core: add auto-detection of 32-bit, 64-bit " John Hubbard
2025-12-03  5:59 ` [PATCH 13/31] gpu: nova-core: Hopper/Blackwell: add FMC firmware image, in support of FSP John Hubbard
2025-12-03  5:59 ` [PATCH 14/31] gpu: nova-core: Hopper/Blackwell: add FSP falcon engine stub John Hubbard
2025-12-03  5:59 ` [PATCH 15/31] gpu: nova-core: Hopper/Blackwell: add FSP falcon EMEM operations John Hubbard
2025-12-03  6:04   ` Timur Tabi
2025-12-03  6:07     ` John Hubbard
2026-01-21 16:06   ` Gary Guo
2026-01-21 16:17     ` Miguel Ojeda
2026-01-23 23:48     ` John Hubbard
2025-12-03  5:59 ` [PATCH 16/31] gpu: nova-core: Hopper/Blackwell: add FSP message infrastructure John Hubbard
2025-12-05 16:47   ` Joel Fernandes
2026-01-03  2:15     ` John Hubbard
2025-12-03  5:59 ` [PATCH 17/31] gpu: nova-core: Hopper/Blackwell: calculate reserved FB heap size John Hubbard
2025-12-03 20:48   ` Timur Tabi
2025-12-04  7:34     ` John Hubbard
2026-01-21 16:10       ` Gary Guo
2026-01-23 23:56         ` John Hubbard
2025-12-03  5:59 ` [PATCH 18/31] gpu: nova-core: Hopper/Blackwell: add needs_large_reserved_mem() John Hubbard
2025-12-03 20:51   ` Timur Tabi
2025-12-04  7:36     ` John Hubbard
2025-12-03  5:59 ` [PATCH 19/31] gpu: nova-core: Hopper/Blackwell: add FSP secure boot completion waiting John Hubbard
2025-12-03  5:59 ` [PATCH 20/31] gpu: nova-core: Hopper/Blackwell: add FSP message structures John Hubbard
2025-12-03  5:59 ` [PATCH 21/31] gpu: nova-core: Hopper/Blackwell: add FMC signature extraction John Hubbard
2025-12-03 15:45   ` Joel Fernandes
2025-12-04  7:55     ` John Hubbard
2026-01-21 16:15   ` Gary Guo
2026-01-24  0:45     ` John Hubbard
2025-12-03  5:59 ` [PATCH 22/31] gpu: nova-core: Hopper/Blackwell: add FSP send/receive messaging John Hubbard
2025-12-03  5:59 ` [PATCH 23/31] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot John Hubbard
2025-12-05 17:15   ` Joel Fernandes [this message]
2025-12-08  6:00     ` John Hubbard
2025-12-06 21:36   ` Joel Fernandes
2025-12-08  6:09     ` John Hubbard
2025-12-03  5:59 ` [PATCH 24/31] gpu: nova-core: Hopper/Blackwell: larger non-WPR heap John Hubbard
2026-01-21 16:18   ` Gary Guo
2026-01-24  1:50     ` John Hubbard
2025-12-03  5:59 ` [PATCH 25/31] gpu: nova-core: Hopper/Blackwell: larger WPR2 (GSP) heap John Hubbard
2025-12-03  5:59 ` [PATCH 26/31] gpu: nova-core: refactor SEC2 booter loading into run_booter() helper John Hubbard
2025-12-03 20:53   ` Timur Tabi
2025-12-04  7:37     ` John Hubbard
2025-12-03  5:59 ` [PATCH 27/31] gpu: nova-core: Hopper/Blackwell: skip GFW boot waiting John Hubbard
2025-12-03  5:59 ` [PATCH 28/31] gpu: nova-core: Hopper/Blackwell: add GSP lockdown release polling John Hubbard
2025-12-03 20:59   ` Timur Tabi
2025-12-04  7:49     ` John Hubbard
2026-01-21 16:20   ` Gary Guo
2026-01-24  1:10     ` John Hubbard
2025-12-03  5:59 ` [PATCH 29/31] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot path John Hubbard
2026-01-21 16:35   ` Gary Guo
2026-01-24  1:38     ` John Hubbard
2026-01-24  1:42       ` John Hubbard
2026-01-26 13:08         ` Gary Guo
2026-01-26 19:53           ` John Hubbard
2025-12-03  5:59 ` [PATCH 30/31] gpu: nova-core: Hopper/Blackwell: new location for PCI config mirror John Hubbard
2025-12-03  5:59 ` [PATCH 31/31] gpu: nova-core: clarify the GPU firmware boot steps John Hubbard

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=dcd18bd8-cb7e-4c28-b4c6-95a201710270@nvidia.com \
    --to=joelagnelf@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --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=epeer@nvidia.com \
    --cc=gary@garyguo.net \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --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

Powered by JetHome