mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joel Fernandes <joelagnelf@nvidia.com>
To: Danilo Krummrich <dakr@kernel.org>,
	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>,
	"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: Tue, 3 Jun 2025 10:29:37 -0400	[thread overview]
Message-ID: <1057c8c0-26c4-4c62-ae7e-ca4d9cd532cf@nvidia.com> (raw)
In-Reply-To: <aD2oROKpaU8Bmyj-@pollux>



On 6/2/2025 9:33 AM, Danilo Krummrich wrote:
[...]
>> +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.
> 

Done, that's a lot cleaner, thanks!

> 
>> +    /// 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?
> 

Good catch, me and Timur were just coincidentally talking about this as well!
Indeed it should not be an error since NPDE on some GPUs doesn't exist.

Will address the other NPDE comments separately since I have to do some research
first. Thanks for double checking.

>> +            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?

Yes, done.

>> +    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.

The main advantage is to use .try_into(). It also documents we're implementing a
conversion from one type to another. I am not sure where the boundary is, but
when you requested me to get rid the other TryFrom(s), I did that but I left
these ones alone because I'd like to use .try_into() for these. I think it makes
sense to convert a BiosImageBase to BiosImage since they're both essentially
similar. Alex, do you have any thoughts on it as you had suggested this for
other usecases during the initial nova-core stub series as well?

Btw, .try_into() does hurt readability a bit even though its more of a
short-hand, since one has to work harder to know what type converts to what, so
I'm really Ok either way here.

> 
>> +    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.

Same comment as above.

>> +    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.

Done, I made this change and it is cleaner. Thanks!

 - Joel



  parent reply	other threads:[~2025-06-03 14:29 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
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 [this message]
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=1057c8c0-26c4-4c62-ae7e-ca4d9cd532cf@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=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=bskeggs@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gary@garyguo.net \
    --cc=jhubbard@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

all inboxes | Powered by JetHome®