Re: [PATCH v2 8/8] gpu: nova-core: add NVKV GSP_INIT schemas

[Eliot Courtney]

On Mon Sep 14, 2026 at 1:11 PM JST, Alexandre Courbot wrote:
> On Thu Aug 27, 2026 at 11:12 PM JST, Eliot Courtney wrote:
> <...>
>> +impl RegKey {
>> +    // Define the Key IDs read/written by GSP.
>> +    const REGKEY_NAME_KEY: KeyId = 0x3070;
>> +    const REGKEY_VALUE_U32_KEY: KeyId = 0x3071;
>> +}
>> +
>> +impl Encodable for KVVec<RegKey> {
>> +    fn encode(&self, encoder: &mut Encoder) -> Result {
>> +        for regkey in self {
>> +            regkey.encode(encoder)?;
>> +        }
>> +        Ok(())
>
> Maybe this is just me misunderstanding, but how are the keys
> sequentially sent here? Because I don't see any mention of an index, and
> `Key::encode` hardcodes `Index::new::<0>()`, so how are these supposed
> to be decoded into an array? The `gsp_init_request` test below only adds
> one key to its `regkeys`, can we add at least another one to see what
> happens and verify that the received content decodes as expected on top
> of checking its length?

You are not misunderstanding, it's just a bit odd. This is because
sequential regkeys are all sent using an index of 0, according to the
protocol. I can add a second regkey into the test to demonstrate this.
We currently don't and won't soon have a need to decode this kind of
repeated index 0 encoding scheme. We have `Accumualted` now, but that
relies on the index changing to know when the previous value has been
completely sent.

To test that the content decodes we'd need to add either a test only
Schema for it, or add a schema that isn't (and won't be soon be) used.
Alternatively, we can test against the encoded byte content directly.
Which do you prefer?

> Also drive-by design question: do we expect to have bidirectional types,
> i.e. types that need to go through `nvkv_encode` and `nvkv_decode`?
> Because I guess there would be some mechanical overlap in the
> definitions for that case. Although maybe we can mitigate that with
> another macro. :)

So far no, but I think it's conceivable in the future. I think in that
case we could call both nvkv_decode! and nvkv_encode!, with decode!'s
schema mapping to the encode!'s struct. You need to specify three
things: 1. how it's decoded, 2. how it's encoded, 3. how it's stored.
This current design, for encoding, puts #2 and #3 in the same place. For
decoding, #1 and #3 are separated (since Schemas may need extra state).
For doing both, I think we can avoid having two instances of #3 for both
encode and decode by using the encode #3 representation for what the
Schema decodes to.