From: Danilo Krummrich <dakr@kernel.org>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: "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" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"John Hubbard" <jhubbard@nvidia.com>,
"Ben Skeggs" <bskeggs@nvidia.com>,
"Joel Fernandes" <joelagnelf@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
"Shirish Baskaran" <sbaskaran@nvidia.com>
Subject: Re: [PATCH v4 16/20] nova-core: Add support for VBIOS ucode extraction for boot
Date: Mon, 2 Jun 2025 15:33:56 +0200 [thread overview]
Message-ID: <aD2oROKpaU8Bmyj-@pollux> (raw)
In-Reply-To: <20250521-nova-frts-v4-16-05dfd4f39479@nvidia.com>
On Wed, May 21, 2025 at 03:45:11PM +0900, Alexandre Courbot wrote:
> +impl Vbios {
<snip>
> + pub(crate) fn fwsec_header(&self, pdev: &device::Device) -> Result<&FalconUCodeDescV3> {
> + self.fwsec_image.fwsec_header(pdev)
> + }
> +
> + pub(crate) fn fwsec_ucode(&self, pdev: &device::Device) -> Result<&[u8]> {
> + self.fwsec_image.fwsec_ucode(pdev, self.fwsec_header(pdev)?)
> + }
> +
> + pub(crate) fn fwsec_sigs(&self, pdev: &device::Device) -> Result<&[u8]> {
> + self.fwsec_image.fwsec_sigs(pdev, self.fwsec_header(pdev)?)
> + }
Can't we just implement Deref here? Why do we need this indirection?
> +impl PcirStruct {
> + fn new(pdev: &pci::Device, data: &[u8]) -> Result<Self> {
> + if data.len() < core::mem::size_of::<PcirStruct>() {
> + dev_err!(pdev.as_ref(), "Not enough data for PcirStruct\n");
> + return Err(EINVAL);
> + }
> +
> + let mut signature = [0u8; 4];
> + signature.copy_from_slice(&data[0..4]);
> +
> + // Signature should be "PCIR" (0x52494350) or "NPDS" (0x5344504e)
> + if &signature != b"PCIR" && &signature != b"NPDS" {
> + dev_err!(
> + pdev.as_ref(),
> + "Invalid signature for PcirStruct: {:?}\n",
> + signature
> + );
> + return Err(EINVAL);
> + }
> +
> + let mut class_code = [0u8; 3];
> + class_code.copy_from_slice(&data[13..16]);
> +
> + Ok(PcirStruct {
> + signature,
> + vendor_id: u16::from_le_bytes([data[4], data[5]]),
> + device_id: u16::from_le_bytes([data[6], data[7]]),
> + device_list_ptr: u16::from_le_bytes([data[8], data[9]]),
> + pci_data_struct_len: u16::from_le_bytes([data[10], data[11]]),
> + pci_data_struct_rev: data[12],
> + class_code,
> + image_len: u16::from_le_bytes([data[16], data[17]]),
> + vendor_rom_rev: u16::from_le_bytes([data[18], data[19]]),
> + code_type: data[20],
> + last_image: data[21],
> + max_runtime_image_len: u16::from_le_bytes([data[22], data[23]]),
> + })
> + }
> +
> + /// Check if this is the last image in the ROM
> + fn is_last(&self) -> bool {
> + self.last_image & LAST_IMAGE_BIT_MASK != 0
> + }
> +
> + /// Calculate image size in bytes
> + fn image_size_bytes(&self) -> Result<usize> {
> + if self.image_len > 0 {
Please make this check when creating the structure...
> + // Image size is in 512-byte blocks
...and make this a type invariant.
> + Ok(self.image_len as usize * 512)
It should also be a type invariant that this does not overflow.
The same applies to NpdeStruct.
> + } else {
> + Err(EINVAL)
> + }
> + }
> +}
<snip>
> + /// Try to find NPDE in the data, the NPDE is right after the PCIR.
> + fn find_in_data(
> + pdev: &pci::Device,
> + data: &[u8],
> + rom_header: &PciRomHeader,
> + pcir: &PcirStruct,
> + ) -> Option<Self> {
> + // Calculate the offset where NPDE might be located
> + // NPDE should be right after the PCIR structure, aligned to 16 bytes
> + let pcir_offset = rom_header.pci_data_struct_offset as usize;
> + let npde_start = (pcir_offset + pcir.pci_data_struct_len as usize + 0x0F) & !0x0F;
What's this magic offset and mask?
> +
> + // Check if we have enough data
> + if npde_start + 11 > data.len() {
'+ 11'?
> + dev_err!(pdev.as_ref(), "Not enough data for NPDE\n");
BiosImageBase declares this as "NVIDIA PCI Data Extension (optional)". If it's
really optional, why is this an error?
> + return None;
> + }
> +
> + // Try to create NPDE from the data
> + NpdeStruct::new(pdev, &data[npde_start..])
> + .inspect_err(|e| {
> + dev_err!(pdev.as_ref(), "Error creating NpdeStruct: {:?}\n", e);
> + })
> + .ok()
So, this returns None if it's a real error. This indicates that the return type
should just be Result<Option<Self>>.
> +struct FwSecBiosPartial {
Since this structure follows the builder pattern, can we please call it
FwSecBiosBuilder?
> + base: BiosImageBase,
> + // FWSEC-specific fields
> + // These are temporary fields that are used during the construction of
> + // the FwSecBiosPartial. Once FwSecBiosPartial is constructed, the
> + // falcon_ucode_offset will be copied into a new FwSecBiosImage.
> +
> + // The offset of the Falcon data from the start of Fwsec image
> + falcon_data_offset: Option<usize>,
> + // The PmuLookupTable starts at the offset of the falcon data pointer
> + pmu_lookup_table: Option<PmuLookupTable>,
> + // The offset of the Falcon ucode
> + falcon_ucode_offset: Option<usize>,
> +}
> +
> +struct FwSecBiosImage {
> + base: BiosImageBase,
> + // The offset of the Falcon ucode
> + falcon_ucode_offset: usize,
> +}
> +
> +// Convert from BiosImageBase to BiosImage
> +impl TryFrom<BiosImageBase> for BiosImage {
Why is this a TryFrom impl, instead of a regular constructor, i.e.
BiosImage::new()?
I don't think this is a canonical conversion.
> + type Error = Error;
> +
> + fn try_from(base: BiosImageBase) -> Result<Self> {
> + match base.pcir.code_type {
> + 0x00 => Ok(BiosImage::PciAt(base.try_into()?)),
> + 0x03 => Ok(BiosImage::Efi(EfiBiosImage { base })),
> + 0x70 => Ok(BiosImage::Nbsi(NbsiBiosImage { base })),
> + 0xE0 => Ok(BiosImage::FwSecPartial(FwSecBiosPartial {
> + base,
> + falcon_data_offset: None,
> + pmu_lookup_table: None,
> + falcon_ucode_offset: None,
> + })),
> + _ => Err(EINVAL),
> + }
> + }
> +}
<snip>
> +impl TryFrom<BiosImageBase> for PciAtBiosImage {
Same here.
> + type Error = Error;
> +
> + fn try_from(base: BiosImageBase) -> Result<Self> {
> + let data_slice = &base.data;
> + let (bit_header, bit_offset) = PciAtBiosImage::find_bit_header(data_slice)?;
> +
> + Ok(PciAtBiosImage {
> + base,
> + bit_header,
> + bit_offset,
> + })
> + }
> +}
<snip>
> +impl FwSecBiosImage {
> + fn new(pdev: &pci::Device, data: FwSecBiosPartial) -> Result<Self> {
Please add a method FwSecBiosBuilder::build() that returns an instance of
FwSecBiosImage instead.
next prev parent reply other threads:[~2025-06-02 13:34 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-21 6:44 [PATCH v4 00/20] nova-core: run FWSEC-FRTS to perform first stage of GSP initialization Alexandre Courbot
2025-05-21 6:44 ` [PATCH v4 01/20] rust: dma: expose the count and size of CoherentAllocation Alexandre Courbot
2025-05-21 8:00 ` Danilo Krummrich
2025-05-22 5:24 ` Alexandre Courbot
2025-05-21 12:43 ` Boqun Feng
2025-05-21 15:57 ` Joel Fernandes
2025-05-21 15:59 ` Joel Fernandes
2025-05-22 5:29 ` Alexandre Courbot
2025-06-02 9:24 ` Danilo Krummrich
2025-05-21 6:44 ` [PATCH v4 02/20] rust: make ETIMEDOUT error available Alexandre Courbot
2025-05-21 7:27 ` Benno Lossin
2025-05-21 6:44 ` [PATCH v4 03/20] rust: sizes: add constants up to SZ_2G Alexandre Courbot
2025-05-21 12:45 ` Boqun Feng
2025-05-21 6:44 ` [PATCH v4 04/20] rust: add new `num` module with useful integer operations Alexandre Courbot
2025-05-22 4:00 ` Alexandre Courbot
2025-05-22 8:44 ` Miguel Ojeda
2025-05-22 9:31 ` Alexandre Courbot
2025-05-28 19:56 ` Alice Ryhl
2025-05-29 1:35 ` Alexandre Courbot
2025-05-28 20:17 ` Benno Lossin
2025-05-29 1:18 ` Alexandre Courbot
2025-05-29 7:27 ` Benno Lossin
2025-06-02 9:39 ` Danilo Krummrich
2025-06-03 22:53 ` Benno Lossin
2025-06-03 23:54 ` Alexandre Courbot
2025-06-04 7:21 ` Benno Lossin
2025-06-02 13:09 ` Alexandre Courbot
2025-06-03 23:02 ` Benno Lossin
2025-06-04 0:05 ` Alexandre Courbot
2025-06-04 7:18 ` Benno Lossin
2025-06-12 13:17 ` Alexandre Courbot
2025-06-12 13:27 ` Alexandre Courbot
2025-06-12 14:49 ` Benno Lossin
2025-06-13 5:31 ` Alexandre Courbot
2025-05-21 6:45 ` [PATCH v4 05/20] gpu: nova-core: use absolute paths in register!() macro Alexandre Courbot
2025-05-30 21:38 ` Lyude Paul
2025-05-21 6:45 ` [PATCH v4 06/20] gpu: nova-core: add delimiter for helper rules " Alexandre Courbot
2025-05-30 21:39 ` Lyude Paul
2025-05-21 6:45 ` [PATCH v4 07/20] gpu: nova-core: expose the offset of each register as a type constant Alexandre Courbot
2025-05-30 21:40 ` Lyude Paul
2025-05-21 6:45 ` [PATCH v4 08/20] gpu: nova-core: allow register aliases Alexandre Courbot
2025-05-21 8:37 ` Danilo Krummrich
2025-05-22 5:14 ` Alexandre Courbot
2025-05-21 6:45 ` [PATCH v4 09/20] gpu: nova-core: increase BAR0 size to 16MB Alexandre Courbot
2025-05-30 21:46 ` Lyude Paul
2025-06-02 11:21 ` Alexandre Courbot
2025-05-21 6:45 ` [PATCH v4 10/20] gpu: nova-core: add helper function to wait on condition Alexandre Courbot
2025-05-21 6:45 ` [PATCH v4 11/20] gpu: nova-core: wait for GFW_BOOT completion Alexandre Courbot
2025-05-30 21:51 ` Lyude Paul
2025-05-31 14:09 ` Miguel Ojeda
2025-05-31 14:37 ` Danilo Krummrich
2025-05-31 14:45 ` Miguel Ojeda
2025-06-02 11:21 ` Alexandre Courbot
2025-05-21 6:45 ` [PATCH v4 12/20] gpu: nova-core: add DMA object struct Alexandre Courbot
2025-05-30 21:53 ` Lyude Paul
2025-05-21 6:45 ` [PATCH v4 13/20] gpu: nova-core: register sysmem flush page Alexandre Courbot
2025-05-30 21:57 ` Lyude Paul
2025-06-02 11:09 ` Danilo Krummrich
2025-06-02 11:20 ` Alexandre Courbot
2025-05-21 6:45 ` [PATCH v4 14/20] gpu: nova-core: add falcon register definitions and base code Alexandre Courbot
2025-05-30 22:22 ` Lyude Paul
2025-06-03 8:03 ` Alexandre Courbot
2025-06-02 12:06 ` Danilo Krummrich
2025-06-03 7:59 ` Alexandre Courbot
2025-05-21 6:45 ` [PATCH v4 15/20] gpu: nova-core: firmware: add ucode descriptor used by FWSEC-FRTS Alexandre Courbot
2025-05-30 22:23 ` Lyude Paul
2025-06-02 12:26 ` Danilo Krummrich
2025-06-04 3:58 ` Alexandre Courbot
2025-05-21 6:45 ` [PATCH v4 16/20] nova-core: Add support for VBIOS ucode extraction for boot Alexandre Courbot
2025-05-27 20:38 ` Joel Fernandes
2025-05-29 6:47 ` Alexandre Courbot
2025-06-03 21:15 ` Lyude Paul
2025-06-05 16:18 ` Joel Fernandes
2025-06-02 13:33 ` Danilo Krummrich [this message]
2025-06-02 15:15 ` Joel Fernandes
2025-06-03 8:12 ` Alexandre Courbot
2025-06-03 13:47 ` Joel Fernandes
2025-06-03 13:49 ` Danilo Krummrich
2025-06-03 14:29 ` Joel Fernandes
2025-06-04 18:23 ` Joel Fernandes
2025-06-03 21:05 ` Lyude Paul
2025-06-04 10:03 ` Miguel Ojeda
2025-06-05 16:09 ` Joel Fernandes
2025-06-05 16:21 ` Danilo Krummrich
2025-06-05 16:28 ` Joel Fernandes
2025-05-21 6:45 ` [PATCH v4 17/20] gpu: nova-core: compute layout of the FRTS region Alexandre Courbot
2025-06-03 21:14 ` Lyude Paul
2025-06-04 4:18 ` Alexandre Courbot
2025-06-04 10:24 ` Danilo Krummrich
2025-06-05 13:14 ` Alexandre Courbot
2025-06-04 10:23 ` Danilo Krummrich
2025-06-05 13:36 ` Alexandre Courbot
2025-05-21 6:45 ` [PATCH v4 18/20] gpu: nova-core: add types for patching firmware binaries Alexandre Courbot
2025-06-03 21:16 ` Lyude Paul
2025-06-04 10:28 ` Danilo Krummrich
2025-06-12 7:19 ` Alexandre Courbot
2025-06-12 10:54 ` Danilo Krummrich
2025-06-12 12:52 ` Alexandre Courbot
2025-05-21 6:45 ` [PATCH v4 19/20] gpu: nova-core: extract FWSEC from BIOS and patch it to run FWSEC-FRTS Alexandre Courbot
2025-06-03 21:32 ` Lyude Paul
2025-06-04 1:11 ` Alexandre Courbot
2025-06-04 10:42 ` Danilo Krummrich
2025-06-12 7:20 ` Alexandre Courbot
2025-05-21 6:45 ` [PATCH v4 20/20] gpu: nova-core: load and " Alexandre Courbot
2025-05-29 21:30 ` Timur Tabi
2025-05-30 22:32 ` Lyude Paul
2025-06-04 1:37 ` Alexandre Courbot
2025-06-03 21:45 ` Lyude Paul
2025-06-04 1:38 ` 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=aD2oROKpaU8Bmyj-@pollux \
--to=dakr@kernel.org \
--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=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bskeggs@nvidia.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=sbaskaran@nvidia.com \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=tzimmermann@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).