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

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

quoted

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