From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Eliot Courtney" <ecourtney@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"John Hubbard" <jhubbard@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@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>, "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>,
nova-gpu@lists.linux.dev, LKML <linux-kernel@vger.kernel.org>,
"Boqun Feng" <boqun@kernel.org>
Subject: Re: [PATCH v13 6/9] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot
Date: Wed, 03 Jun 2026 22:35:11 +0900 [thread overview]
Message-ID: <DIZGCEZRJZNN.2G2A9HFUIDBOU@nvidia.com> (raw)
In-Reply-To: <DIZFC4HD8M35.36YODW6I2HAMK@nvidia.com>
On Wed Jun 3, 2026 at 9:47 PM JST, Eliot Courtney wrote:
> On Wed Jun 3, 2026 at 4:30 PM JST, Alexandre Courbot wrote:
>> From: John Hubbard <jhubbard@nvidia.com>
>>
>> Build and send the Chain of Trust message to FSP, bundling the
>> DMA-coherent boot parameters that FSP reads at boot time.
>>
>> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
>> Co-developed-by: Alexandre Courbot <acourbot@nvidia.com>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>> ---
>> drivers/gpu/nova-core/firmware/fsp.rs | 2 -
>> drivers/gpu/nova-core/fsp.rs | 145 +++++++++++++++++++++-
>> drivers/gpu/nova-core/fsp/hal.rs | 1 -
>> drivers/gpu/nova-core/gsp.rs | 1 +
>> drivers/gpu/nova-core/gsp/fw.rs | 65 ++++++++++
>> drivers/gpu/nova-core/gsp/fw/r570_144/bindings.rs | 82 ++++++++++++
>> drivers/gpu/nova-core/gsp/hal/gh100.rs | 23 +++-
>> drivers/gpu/nova-core/mctp.rs | 2 -
>> 8 files changed, 308 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/nova-core/firmware/fsp.rs b/drivers/gpu/nova-core/firmware/fsp.rs
>> index 9b211426a75a..6eaf1c684b9d 100644
>> --- a/drivers/gpu/nova-core/firmware/fsp.rs
>> +++ b/drivers/gpu/nova-core/firmware/fsp.rs
>> @@ -39,10 +39,8 @@ pub(crate) struct FmcSignatures {
>>
>> pub(crate) struct FspFirmware {
>> /// FMC firmware image data (only the "image" ELF section).
>> - #[expect(dead_code)]
>> pub(crate) fmc_image: Coherent<[u8]>,
>> /// FMC firmware signatures.
>> - #[expect(dead_code)]
>> pub(crate) fmc_sigs: KBox<FmcSignatures>,
>> }
>>
>> diff --git a/drivers/gpu/nova-core/fsp.rs b/drivers/gpu/nova-core/fsp.rs
>> index cedfea173e50..883ac4f8b811 100644
>> --- a/drivers/gpu/nova-core/fsp.rs
>> +++ b/drivers/gpu/nova-core/fsp.rs
>> @@ -9,8 +9,14 @@
>>
>> use kernel::{
>> device,
>> + dma::Coherent,
>> io::poll::read_poll_timeout,
>> prelude::*,
>> + ptr::{
>> + Alignable,
>> + Alignment, //
>> + },
>> + sizes::SZ_2M,
>> time::Delta,
>> transmute::{
>> AsBytes,
>> @@ -24,13 +30,19 @@
>> fsp::Fsp as FspEngine,
>> Falcon, //
>> },
>> - firmware::fsp::FspFirmware,
>> + fb::FbLayout,
>> + firmware::fsp::{
>> + FmcSignatures,
>> + FspFirmware, //
>> + },
>> gpu::Chipset,
>> + gsp::GspFmcBootParams,
>> mctp::{
>> MctpHeader,
>> NvdmHeader,
>> NvdmType, //
>> },
>> + num,
>> regs, //
>> };
>>
>> @@ -66,6 +78,114 @@ pub(crate) trait MessageToFsp: AsBytes {
>> const NVDM_TYPE: NvdmType;
>> }
>>
>> +/// NVDM (NVIDIA Data Model) CoT (Chain of Trust) payload, the main
>> +/// message body sent to FSP for Chain of Trust boot.
>> +#[repr(C, packed)]
>> +#[derive(Clone, Copy, Zeroable)]
>> +struct NvdmPayloadCot {
>> + version: u16,
>> + size: u16,
>> + gsp_fmc_sysmem_offset: u64,
>> + frts_sysmem_offset: u64,
>> + frts_sysmem_size: u32,
>> + frts_vidmem_offset: u64,
>> + frts_vidmem_size: u32,
>> + sigs: FmcSignatures,
>> + gsp_boot_args_sysmem_offset: u64,
>> +}
>> +
>> +/// Complete FSP message structure with MCTP and NVDM headers.
>> +#[repr(C)]
>> +#[derive(Clone, Copy)]
>> +struct FspMessage {
>> + mctp_header: MctpHeader,
>> + nvdm_header: NvdmHeader,
>> + cot: NvdmPayloadCot,
>> +}
>> +
>> +impl FspMessage {
>> + /// Returns an in-place initializer for [`FspMessage`].
>> + fn new<'a>(
>> + fb_layout: &FbLayout,
>> + fsp_fw: &'a FspFirmware,
>> + args: &'a FmcBootArgs,
>> + ) -> Result<impl Init<Self> + 'a> {
>> + // frts_offset is relative to FB end: FRTS_location = FB_END - frts_offset
>> + let frts_offset = if !args.resume {
>> + let frts_reserved_size = fb_layout.heap.len() + u64::from(fb_layout.pmu_reserved_size);
>> +
>> + frts_reserved_size
>> + .align_up(Alignment::new::<SZ_2M>())
>> + .ok_or(EINVAL)?
>
> Why is `frts_offset` calculated using heap and pmu_reserved_size rather
> than looking at `fb_layout.frts`? If `fb_layout.frts` is the location we
> are meant to have the frts in then why use a (potentially) different
> location?
Conceptually the current code looks correct, but the naming is indeed
ambiguous. This seems to correspond to the CoT `frtsVidmemOffset`, not
the absolute FRTS address from `fb_layout.frts`. Will need to dig a bit
deeper but it looks like this requires a different name.
>
>> + } else {
>> + 0
>> + };
>> +
>> + let frts_size: u32 = if !args.resume {
>> + fb_layout.frts.len().try_into()?
>> + } else {
>> + 0
>> + };
>> +
>> + let version = hal::fsp_hal(args.chipset).ok_or(ENOTSUPP)?.cot_version();
>> + let size = num::usize_into_u16::<{ core::mem::size_of::<NvdmPayloadCot>() }>();
>> +
>> + Ok(init!(Self {
>> + mctp_header: MctpHeader::single_packet(),
>> + nvdm_header: NvdmHeader::new(NvdmType::Cot),
>> + // The payload is packed, so we cannot use `init!`. Initialize it member-by-member using
>> + // `chain`.
>> + cot <- pin_init::init_zeroed(),
>> + })
>> + .chain(move |msg| {
>> + msg.cot.version = version;
>> + msg.cot.size = size;
>> + msg.cot.gsp_fmc_sysmem_offset = fsp_fw.fmc_image.dma_handle();
>> + msg.cot.frts_vidmem_offset = frts_offset;
>> + msg.cot.frts_vidmem_size = frts_size;
>> + msg.cot.gsp_boot_args_sysmem_offset = args.fmc_boot_params.dma_handle();
>> + msg.cot.sigs = *fsp_fw.fmc_sigs;
>
> I guess we are leaving sysmem frts unset for now since we don't use it
> for anything hey
Yes, but let me add a note so we don't forget to come back to this as
they will likely become needed for systems without VRAM.
next prev parent reply other threads:[~2026-06-03 13:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 7:30 [PATCH v13 0/9] gpu: nova-core: Hopper/Blackwell support Alexandre Courbot
2026-06-03 7:30 ` [PATCH v13 1/9] gpu: nova-core: Hopper/Blackwell: add FSP falcon EMEM operations Alexandre Courbot
2026-06-03 10:49 ` Eliot Courtney
2026-06-03 7:30 ` [PATCH v13 2/9] gpu: nova-core: Hopper/Blackwell: add FSP message infrastructure Alexandre Courbot
2026-06-03 10:50 ` Eliot Courtney
2026-06-03 7:30 ` [PATCH v13 3/9] gpu: nova-core: add MCTP/NVDM protocol types for firmware communication Alexandre Courbot
2026-06-03 7:30 ` [PATCH v13 4/9] gpu: nova-core: Hopper/Blackwell: add FSP send/receive messaging Alexandre Courbot
2026-06-03 10:57 ` Eliot Courtney
2026-06-03 7:30 ` [PATCH v13 5/9] gpu: nova-core: Hopper/Blackwell: select FSP Chain of Trust version Alexandre Courbot
2026-06-03 7:30 ` [PATCH v13 6/9] gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot Alexandre Courbot
2026-06-03 12:47 ` Eliot Courtney
2026-06-03 13:35 ` Alexandre Courbot [this message]
2026-06-03 7:30 ` [PATCH v13 7/9] gpu: nova-core: Hopper/Blackwell: add GSP lockdown release polling Alexandre Courbot
2026-06-03 10:17 ` Alexandre Courbot
2026-06-03 11:53 ` Eliot Courtney
2026-06-03 14:53 ` Alexandre Courbot
2026-06-03 7:30 ` [PATCH v13 8/9] gpu: nova-core: add non-sec2 unload path Alexandre Courbot
2026-06-03 7:30 ` [PATCH v13 9/9] gpu: nova-core: gsp: enable FSP boot path Alexandre Courbot
2026-06-03 11:04 ` Eliot Courtney
2026-06-03 15:04 ` [PATCH v13 0/9] gpu: nova-core: 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=DIZGCEZRJZNN.2G2A9HFUIDBOU@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.