All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Joel Fernandes" <joelagnelf@nvidia.com>,
	"Eliot Courtney" <ecourtney@nvidia.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>
Cc: "John Hubbard" <jhubbard@nvidia.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	"Timur Tabi" <ttabi@nvidia.com>, <rust-for-linux@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 08/11] gpu: nova-core: vbios: compute FWSEC-relative Falcon data offset
Date: Tue, 21 Apr 2026 18:46:04 +0900	[thread overview]
Message-ID: <DHYQJKFXZ3EB.26LTASWWWS2GY@nvidia.com> (raw)
In-Reply-To: <e1e869be-a681-420e-8a31-d9857f1c28f4@nvidia.com>

On Tue Apr 21, 2026 at 6:46 AM JST, Joel Fernandes wrote:
>
>
> On 4/16/2026 10:41 PM, Eliot Courtney wrote:
>> On Fri Apr 17, 2026 at 1:13 AM JST, Joel Fernandes wrote:
>>> On 4/14/2026 7:54 AM, Eliot Courtney wrote:
>>>> Push the computation of the falcon data offset into a helper function.
>>>> The subtraction to create the offset should be checked, and by doing
>>>> this the check can be folded into the existing check in
>>>> `falcon_data_ptr`.
>>>>
>>>> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
>>>> ---
>>>>  drivers/gpu/nova-core/vbios.rs | 48 +++++++++++++++++-------------------------
>>>>  1 file changed, 19 insertions(+), 29 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/nova-core/vbios.rs b/drivers/gpu/nova-core/vbios.rs
>>>> index 01f65d50cbb3..0c0e0402e715 100644
>>>> --- a/drivers/gpu/nova-core/vbios.rs
>>>> +++ b/drivers/gpu/nova-core/vbios.rs
>>>> @@ -765,33 +765,29 @@ fn get_bit_token(&self, token_id: u8) -> Result<BitToken> {
>>>>          BitToken::from_id(self, token_id)
>>>>      }
>>>>  
>>>> -    /// Find the Falcon data pointer structure in the [`PciAtBiosImage`].
>>>> +    /// Find the Falcon data offset from the start of the FWSEC region.
>>>
>>> The comment change is incorrect, this subtraction is just for normalizing.
>>> It basically normalizes the pointer wrt the PciAt image.
>>>
>>> It is only after the following in the caller that we get the true offset
>>> within the FWSEC.
>>>             offset -= first_fwsec.base.data.len();
>>>
>>> I suggest, let us rename falcon_data_offset() to
>>> falcon_normalize_fwsec_offset() and update the comment above.
>> 
>> Thanks for your reviews! W.r.t. this, my understanding is that the
>> layout is something like:
>> 
>> PCI-AT | Efi? | FWSEC | FWSEC
>> 
>> And that the falcon data pointer that we get out of PCI-AT starts off
>> like this (indicated by ^):
>> 
>> ^ PCI-AT | Efi? | FWSEC | FWSEC
>> 
>> But the actual "address space" it's in is:
>> 
>> ^ PCI-AT | FWSEC | FWSEC
>> 
>> Because it doesn't count whatever images are between PCI-AT and the
>> first FWSEC as part of that space. So by subtracting the PCI-AT size, we
>> convert it to this logical space:
>> 
>> ^ FWSEC | FWSEC
>> 
>> Based on the above understanding doesn't it make sense to say that
>> `falcon_data_offset` transforms the pointer to be relative from the
>> start of the FWSEC region? Once we subtract off the first fwsec image
>> length, it's then relative to the second FWSEC image. Please LMK if I've
>> missed something. We could also emphasise in the doc that the "FWSEC
>> region" means the contiguous region defined by the first two FWSEC
>> images. WDYT?
>
> You did not miss anything, your explanation above is spot-on.
>
> You could also keep your function name and add a comment on top of
> `falcon_data_offset()`. Something like "offset from the end of PCI-AT
> (i.e., the start of the combined FWSEC region)". Sounds good?

Yerp SG. I realised I sent the next version without applying this
feedback, sorry! But I do agree. I think we can strengthen it by saying
the offset from the /combined/ FWSEC region like you suggest, and maybe
mention that there may be an EFI after the end of PCI-AT.

thanks

  reply	other threads:[~2026-04-21  9:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 11:54 [PATCH v2 00/11] gpu: nova-core: vbios: harden various array accesses and refactor Eliot Courtney
2026-04-14 11:54 ` [PATCH v2 01/11] gpu: nova-core: vbios: fix various cases of reading past `BIOS_MAX_SCAN_LEN` Eliot Courtney
2026-04-14 11:54 ` [PATCH v2 02/11] gpu: nova-core: vbios: limit `BitToken` entry reads Eliot Courtney
2026-04-14 11:54 ` [PATCH v2 03/11] gpu: nova-core: vbios: use checked ops and accesses in `FwSecBiosImage::ucode` Eliot Courtney
2026-04-14 11:54 ` [PATCH v2 04/11] gpu: nova-core: vbios: use checked access in `FwSecBiosImage::header` Eliot Courtney
2026-04-16 16:20   ` Joel Fernandes
2026-04-14 11:54 ` [PATCH v2 05/11] gpu: nova-core: vbios: use checked accesses in `setup_falcon_data` Eliot Courtney
2026-04-16 16:14   ` Joel Fernandes
2026-04-14 11:54 ` [PATCH v2 06/11] gpu: nova-core: vbios: drop unused falcon_data_offset from FwSecBiosBuilder Eliot Courtney
2026-04-16 16:14   ` Joel Fernandes
2026-04-14 11:54 ` [PATCH v2 07/11] gpu: nova-core: vbios: keep PmuLookupTable local in setup_falcon_data Eliot Courtney
2026-04-16 15:56   ` Joel Fernandes
2026-04-14 11:54 ` [PATCH v2 08/11] gpu: nova-core: vbios: compute FWSEC-relative Falcon data offset Eliot Courtney
2026-04-16 16:13   ` Joel Fernandes
2026-04-17  2:41     ` Eliot Courtney
2026-04-20 21:46       ` Joel Fernandes
2026-04-21  9:46         ` Eliot Courtney [this message]
2026-04-14 11:54 ` [PATCH v2 09/11] gpu: nova-core: vbios: simplify setup_falcon_data Eliot Courtney
2026-04-16 15:30   ` Joel Fernandes
2026-04-17  2:07     ` Eliot Courtney
2026-04-14 11:54 ` [PATCH v2 10/11] gpu: nova-core: vbios: construct `FwSecBiosImage` directly from BIOS images Eliot Courtney
2026-04-16 15:54   ` Joel Fernandes
2026-04-14 11:54 ` [PATCH v2 11/11] gpu: nova-core: vbios: reject extra PCI-AT and FWSEC images Eliot Courtney
2026-04-14 23:39   ` Timur Tabi
2026-04-15  0:02     ` Joel Fernandes
2026-04-17  2:34       ` Eliot Courtney
2026-04-21 14:45         ` Joel Fernandes
2026-04-21 16:01           ` Timur Tabi
2026-04-21 16:09             ` Joel Fernandes

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=DHYQJKFXZ3EB.26LTASWWWS2GY@nvidia.com \
    --to=ecourtney@nvidia.com \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jhubbard@nvidia.com \
    --cc=joelagnelf@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=ttabi@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.