From: "Eliot Courtney" <ecourtney@nvidia.com>
To: "Alexandre Courbot" <acourbot@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
"Uladzislau Rezki" <urezki@gmail.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@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>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Tamir Duberstein" <tamird@kernel.org>,
"Onur Özkan" <work@onurozkan.dev>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org,
dri-devel <dri-devel-bounces@lists.freedesktop.org>
Subject: Re: [PATCH v2 5/8] gpu: nova-core: add NVKV decoder
Date: Mon, 14 Sep 2026 13:45:12 +0900 [thread overview]
Message-ID: <DLERKQXXR6W4.1K44N4T2IS6UY@nvidia.com> (raw)
In-Reply-To: <DLAIIHELWF8H.3KAZJV8DOIJ6O@nvidia.com>
On Wed Sep 9, 2026 at 1:48 PM JST, Alexandre Courbot wrote:
> On Wed Sep 9, 2026 at 10:13 AM JST, Eliot Courtney wrote:
>> On Wed Sep 9, 2026 at 9:51 AM JST, Alexandre Courbot wrote:
>>> On Thu Aug 27, 2026 at 11:12 PM JST, Eliot Courtney wrote:
>>>> Add a decoder for NVKV. This is for receiving messages from GSP for
>>>> GMCAPI calls. The NVKV format essentially encodes a sequence of function
>>>> calls f(key, index, value). This decoder reads an encoded stream and
>>>> invokes a type implementing the new `Schema` visitor trait. The
>>>> `Schema` trait can either consume the value or not, which is useful for
>>>> composing Schemas. If a (key, index, value) is not consumed, error out
>>>> depending on `UnknownKeyPolicy`. Whether ignoring unknown keys is ok or
>>>> not is per each GMCAPI call.
>>>>
>>>> Add kunit tests for the decoder.
>>>>
>>>> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
>>>> ---
>>>> drivers/gpu/nova-core/gsp/nvkv.rs | 3 +
>>>> drivers/gpu/nova-core/gsp/nvkv/decode.rs | 265 +++++++++++++++++++++++++++++++
>>>> 2 files changed, 268 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/nova-core/gsp/nvkv.rs b/drivers/gpu/nova-core/gsp/nvkv.rs
>>>> index a8e16687a134..cbeee7f376b6 100644
>>>> --- a/drivers/gpu/nova-core/gsp/nvkv.rs
>>>> +++ b/drivers/gpu/nova-core/gsp/nvkv.rs
>>>> @@ -27,6 +27,9 @@
>>>> mod encode;
>>>> pub(crate) use encode::*;
>>>>
>>>> +mod decode;
>>>> +pub(crate) use decode::*;
>>>> +
>>>> /// The allocator backing [`EncodedStream`].
>>>> type StreamAllocator = KVmalloc;
>>>>
>>>> diff --git a/drivers/gpu/nova-core/gsp/nvkv/decode.rs b/drivers/gpu/nova-core/gsp/nvkv/decode.rs
>>>> new file mode 100644
>>>> index 000000000000..ceb97e73e100
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/nova-core/gsp/nvkv/decode.rs
>>>> @@ -0,0 +1,265 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +// SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
>>>> +
>>>> +#![cfg_attr(not(CONFIG_KUNIT), expect(dead_code))]
>>>> +
>>>> +use kernel::prelude::*;
>>>> +
>>>> +use crate::gsp::nvkv::{
>>>> + Index,
>>>> + KeyId,
>>>> + Op,
>>>> + Opcode, //
>>>> +};
>>>> +use crate::num;
>>>> +
>>>> +/// A decoded NVKV value.
>>>> +#[derive(Copy, Clone)]
>>>> +pub(crate) enum DecoderValue<'a> {
>>>> + Scalar32(u32),
>>>> + Scalar64(u64),
>>>> + Array8(&'a [u8]),
>>>> + Array32(&'a [u32]),
>>>> + Array64(&'a [u64]),
>>>> +}
>>>> +
>>>> +/// Implements `TryFrom` from the given `DecoderValue` variant to the given type.
>>>> +///
>>>> +/// `TryFrom` is used by the `Schema` implementations in this file to convert from the
>>>> +/// `DecoderValue`s into the types to store. Provide the implementations for basic types here.
>>>> +macro_rules! impl_try_from_decoder_value {
>>>> + ($ty:ty, $variant:ident) => {
>>>> + impl<'a> TryFrom<DecoderValue<'a>> for $ty {
>>>> + type Error = Error;
>>>> +
>>>> + fn try_from(value: DecoderValue<'a>) -> Result<Self> {
>>>> + if let DecoderValue::$variant(v) = value {
>>>> + Ok(v)
>>>> + } else {
>>>> + Err(EINVAL)
>>>> + }
>>>> + }
>>>> + }
>>>> + };
>>>> +}
>>>> +
>>>> +impl_try_from_decoder_value!(u32, Scalar32);
>>>> +impl_try_from_decoder_value!(u64, Scalar64);
>>>> +impl_try_from_decoder_value!(&'a [u8], Array8);
>>>> +impl_try_from_decoder_value!(&'a [u32], Array32);
>>>> +impl_try_from_decoder_value!(&'a [u64], Array64);
>>>> +
>>>> +/// A visitor that consumes decoded NVKV and produces a `Target`.
>>>> +pub(crate) trait Schema {
>>>> + type Target;
>>>> +
>>>> + /// Visits one decoded pair. Returns `Ok(true)` if the schema consumed it.
>>>> + fn visit<'a>(&mut self, key: KeyId, index: Index, value: DecoderValue<'a>) -> Result<bool>;
>>>> +
>>>> + /// Returns an initializer that makes the decoded `Target`.
>>>> + ///
>>>> + /// After the returned initializer runs, the schema should be empty again.
>>>> + fn finish(&mut self) -> impl Init<Self::Target, Error> + '_;
>>>
>>> Would it make sense to make `finish` consume `self`? Because "the schema
>>> should be empty again" sounds like an implicit contract not everybody
>>> will think about enforcing, which could be a source of subtle bugs.
>>
>> Yeah, it would make sense, and that's what v1 of this series did. But, I
>> noticed that it forced materialisation of the Schema on the stack (and
>> the Schema can be large), even if you allocate the Schema using a Box.
>>
>> There's two places where it materialises - in Decoder::decode and also
>> in Accumulated.
>>
>> anyway, that's why I changed it to the valid-but-empty like convention.
>> Please LMK if you think there's a better trade off solution to avoiding
>> materialising this on the stack.
>
> Indeed, I don't see a way around it. In this case can we make the
> requirement stronger than "should be empty" in the doc? Because AFAIU
> caller code depends on this behavior, although most of this is handled
> by `nvkv_decode`, so we are working in a controlled environment here.
Yes, I'll strengthen the wording, sgtm.
next prev parent reply other threads:[~2026-09-14 4:45 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 14:12 [PATCH v2 0/8] gpu: nova-core: add NVKV codec Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 1/8] rust: alloc: add Vec::try_push_init Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 2/8] rust: alloc: add Vec::push_init Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 3/8] rust: alloc: add ArrayVec Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 4/8] gpu: nova-core: add NVKV encoder Eliot Courtney
2026-09-07 15:07 ` Alexandre Courbot
2026-09-14 4:44 ` Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 5/8] gpu: nova-core: add NVKV decoder Eliot Courtney
2026-09-09 0:51 ` Alexandre Courbot
2026-09-09 1:13 ` Eliot Courtney
2026-09-09 4:48 ` Alexandre Courbot
2026-09-14 4:45 ` Eliot Courtney [this message]
2026-09-10 7:47 ` Alexandre Courbot
2026-09-14 5:45 ` Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 6/8] gpu: nova-core: add NVKV typed encoding Eliot Courtney
2026-09-10 8:10 ` Alexandre Courbot
2026-09-11 5:17 ` Alexandre Courbot
2026-09-11 5:28 ` Eliot Courtney
2026-09-11 11:18 ` Alexandre Courbot
2026-09-14 4:46 ` Eliot Courtney
2026-08-27 14:12 ` [PATCH v2 7/8] gpu: nova-core: add NVKV typed decoding Eliot Courtney
2026-09-14 3:46 ` Alexandre Courbot
2026-09-14 6:55 ` Eliot Courtney
2026-09-14 7:04 ` John Hubbard
2026-09-14 7:16 ` Eliot Courtney
2026-09-14 12:06 ` Alexandre Courbot
2026-08-27 14:12 ` [PATCH v2 8/8] gpu: nova-core: add NVKV GSP_INIT schemas Eliot Courtney
2026-09-14 4:11 ` Alexandre Courbot
2026-09-14 5:42 ` Eliot Courtney
2026-09-14 12:12 ` 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=DLERKQXXR6W4.1K44N4T2IS6UY@nvidia.com \
--to=ecourtney@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel-bounces@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=lossin@kernel.org \
--cc=nova-gpu@lists.linux.dev \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tamird@kernel.org \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=urezki@gmail.com \
--cc=vbabka@kernel.org \
--cc=work@onurozkan.dev \
/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®