Re: SVSM Observability and Configuration Protocol draft

Jörg Rödel <[email protected]> Tue, 14 Apr 2026 11:07:14 +0200
Newsgroups dev.linux.lists.coconut-svsm
Message-ID <u3espexb4toaxc6w5sz6w72hgbwep2chgj2ej4op2ye3z5lys5@5o6ihdapythk>
Hi Nicolai,

On Tue, Apr 14, 2026 at 10:46:33AM +0200, Nicolai Stange wrote:
> > | Offset | Size (Bytes) | Description                         |
> > |-------:|-------------:|-------------------------------------|
> > | `0x00` | 4            | Flags                               |
> > | `0x04` | 124          | Name of the source encoded as UTF-8 |
> 
> Just a generic comment: as in my understanding there's no central
> authority managing the names, would it perhaps make sense to split the
> Name from above into something like a 16 byte UUID + a human readable
> name, the latter being only informative (or, alternatively, whose
> semantics are defined only within the scope of the UUID)?

I am not sure how much value UUIDs add because the read operations work on
indexes, but I agree that it makes sense to have a defined set of fixed sources
with their indexes as part of the spec. The question is what should be
pre-defined besides the log buffer?

> > The format of the data allowed to write is source dependent. If a given data
> > format is not understood by the source the call will also return
> > `SVSM_ERR_INVALID_PARAMETER`.
> 
> I assume other errors would be allowed as well? I'm thinking of a
> situation where a "source/configuration" is backed by storage, and
> writes to that could fail.

True, maybe it makes sense to add some protocol-specific error codes in the
0x8000_0000-0xFFFF_FFFF range.

-Joerg