All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Lyude Paul" <lyude@redhat.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" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"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>
Cc: "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>
Subject: Re: [PATCH v4 19/20] gpu: nova-core: extract FWSEC from BIOS and patch it to run FWSEC-FRTS
Date: Wed, 04 Jun 2025 10:11:41 +0900	[thread overview]
Message-ID: <DADCKUVFXPLH.2DWHTBQ76T3PD@nvidia.com> (raw)
In-Reply-To: <3212029a1f4d671aaa2b48e2e917d5c810f5c769.camel@redhat.com>

On Wed Jun 4, 2025 at 6:32 AM JST, Lyude Paul wrote:
<snip>
>> +unsafe fn transmute<'a, 'b, T: Sized + FromBytes>(
>> +    fw: &'a DmaObject,
>> +    offset: usize,
>> +) -> Result<&'b T> {
>> +    if offset + core::mem::size_of::<T>() > fw.size() {
>> +        return Err(EINVAL);
>> +    }
>> +    if (fw.start_ptr() as usize + offset) % core::mem::align_of::<T>() != 0 {
>> +        return Err(EINVAL);
>> +    }
>> +
>> +    // SAFETY: we have checked that the pointer is properly aligned that its pointed memory is
>> +    // large enough the contains an instance of `T`, which implements `FromBytes`.
>> +    Ok(unsafe { &*(fw.start_ptr().add(offset) as *const T) })
>
> Why not .cast()?

No reason - fixed, thanks!

>
>> +}
>> +
>> +/// Reinterpret the area starting from `offset` in `fw` as a mutable instance of `T` (which must
>> +/// implement [`FromBytes`]) and return a reference to it.
>> +///
>> +/// # Safety
>> +///
>> +/// Callers must ensure that the region of memory returned is not read or written for as long as
>> +/// the returned reference is alive.
>> +unsafe fn transmute_mut<'a, 'b, T: Sized + FromBytes>(
>> +    fw: &'a mut DmaObject,
>> +    offset: usize,
>> +) -> Result<&'b mut T> {
>> +    if offset + core::mem::size_of::<T>() > fw.size() {
>> +        return Err(EINVAL);
>> +    }
>> +    if (fw.start_ptr_mut() as usize + offset) % core::mem::align_of::<T>() != 0 {
>> +        return Err(EINVAL);
>> +    }
>> +
>> +    // SAFETY: we have checked that the pointer is properly aligned that its pointed memory is
>> +    // large enough the contains an instance of `T`, which implements `FromBytes`.
>> +    Ok(unsafe { &mut *(fw.start_ptr_mut().add(offset) as *mut T) })
>> +}
>> +
>> +impl FirmwareDmaObject<FwsecFirmware> {
>> +    /// Patch the Fwsec firmware image in `fw` to run the command `cmd`.
>> +    fn patch_command(&mut self, v3_desc: &FalconUCodeDescV3, cmd: FwsecCommand) -> Result<()> {
>> +        let hdr_offset = (v3_desc.imem_load_size + v3_desc.interface_offset) as usize;
>> +        // SAFETY: we have an exclusive reference to `self`, and no caller should have shared
>> +        // `self` with the hardware yet.
>> +        let hdr: &FalconAppifHdrV1 = unsafe { transmute(&self.0, hdr_offset) }?;
>> +
>> +        if hdr.version != 1 {
>> +            return Err(EINVAL);
>> +        }
>> +
>> +        // Find the DMEM mapper section in the firmware.
>> +        for i in 0..hdr.entry_count as usize {
>> +            let app: &FalconAppifV1 =
>> +            // SAFETY: we have an exclusive reference to `self`, and no caller should have shared
>> +            // `self` with the hardware yet.
>> +            unsafe {
>> +                transmute(
>> +                    &self.0,
>> +                    hdr_offset + hdr.header_size as usize + i * hdr.entry_size as usize
>> +                )
>> +            }?;
>> +
>> +            if app.id != NVFW_FALCON_APPIF_ID_DMEMMAPPER {
>> +                continue;
>> +            }
>> +
>> +            // SAFETY: we have an exclusive reference to `self`, and no caller should have shared
>> +            // `self` with the hardware yet.
>> +            let dmem_mapper: &mut FalconAppifDmemmapperV3 = unsafe {
>> +                transmute_mut(
>> +                    &mut self.0,
>> +                    (v3_desc.imem_load_size + app.dmem_base) as usize,
>> +                )
>> +            }?;
>> +
>> +            // SAFETY: we have an exclusive reference to `self`, and no caller should have shared
>> +            // `self` with the hardware yet.
>> +            let frts_cmd: &mut FrtsCmd = unsafe {
>> +                transmute_mut(
>> +                    &mut self.0,
>> +                    (v3_desc.imem_load_size + dmem_mapper.cmd_in_buffer_offset) as usize,
>> +                )
>> +            }?;
>> +
>> +            frts_cmd.read_vbios = ReadVbios {
>> +                ver: 1,
>> +                hdr: core::mem::size_of::<ReadVbios>() as u32,
>
> I think if we're using size_of and align_of this many times it would be worth
> just importing it

Indeed, especially since they seem to already be imported by the kernel
prelude.

>
>> +                addr: 0,
>> +                size: 0,
>> +                flags: 2,
>> +            };
>> +
>> +            dmem_mapper.init_cmd = match cmd {
>> +                FwsecCommand::Frts {
>> +                    frts_addr,
>> +                    frts_size,
>> +                } => {
>> +                    frts_cmd.frts_region = FrtsRegion {
>> +                        ver: 1,
>> +                        hdr: core::mem::size_of::<FrtsRegion>() as u32,
>> +                        addr: (frts_addr >> 12) as u32,
>> +                        size: (frts_size >> 12) as u32,
>> +                        ftype: NVFW_FRTS_CMD_REGION_TYPE_FB,
>> +                    };
>> +
>> +                    NVFW_FALCON_APPIF_DMEMMAPPER_CMD_FRTS
>> +                }
>> +                FwsecCommand::Sb => NVFW_FALCON_APPIF_DMEMMAPPER_CMD_SB,
>> +            };
>> +
>> +            // Return early as we found and patched the DMEMMAPPER region.
>> +            return Ok(());
>> +        }
>> +
>> +        Err(ENOTSUPP)
>> +    }
>> +}
>> +
>> +/// The FWSEC microcode, extracted from the BIOS and to be run on the GSP falcon.
>> +///
>> +/// It is responsible for e.g. carving out the WPR2 region as the first step of the GSP bootflow.
>> +pub(crate) struct FwsecFirmware {
>> +    desc: FalconUCodeDescV3,
>> +    ucode: FirmwareDmaObject<Self>,
>> +}
>> +
>> +impl FalconLoadParams for FwsecFirmware {
>> +    fn imem_load_params(&self) -> FalconLoadTarget {
>> +        FalconLoadTarget {
>> +            src_start: 0,
>> +            dst_start: self.desc.imem_phys_base,
>> +            len: self.desc.imem_load_size,
>> +        }
>> +    }
>> +
>> +    fn dmem_load_params(&self) -> FalconLoadTarget {
>> +        FalconLoadTarget {
>> +            src_start: self.desc.imem_load_size,
>> +            dst_start: self.desc.dmem_phys_base,
>> +            len: Layout::from_size_align(self.desc.dmem_load_size as usize, 256)
>> +                // Cannot panic, as 256 is non-zero and a power of 2.
>> +                .unwrap()
>
> Why not just unwrap_unchecked() then? Or do we still want a possible panic
> here just to make sure we didn't make a mistake?

`unwrap_unchecked` requires an `unsafe` block, which I think it not
really worth here. I'd expect the compiler to optimize the `unwrap` out
anyway.


  reply	other threads:[~2025-06-04  1:11 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
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 [this message]
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=DADCKUVFXPLH.2DWHTBQ76T3PD@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=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=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --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=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 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.