Re: SVSM Observability and Configuration Protocol draft

Hi,

On 4/14/26 10:25 AM, Jörg Rödel wrote:
> # **[DRAFT]** SVSM Observability and Configuration Protocol
> 
> The SVSM Observability and Configuration Protocol (OCP) is a new sub-protocol
> of the SVSM specification and uses protocol ID value 5. The initial version of
> the OCP is 1. Versioning is strictly additive, i.e., all calls present in a
> protocol version must also be present in any later version.

Maybe we could have a short rationale section with e.g. expected use
cases for the protocol.

> 
> The following enumerates the set of calls supported by version 1 of the OCP:
> 
> | Call ID | First version supported | Name | Function |
> |--------:|------------------------:|------|----------|
> | 0 | 1 | `SVSM_OCP_LIST` | Query a list of supported observability and configuration sources. |
> | 1 | 1 | `SVSM_OCP_READ` | Read data from an observability source. |
> | 2 | 1 | `SVSM_OCP_WRITE` | Write data to a configuration source. |

I could see some cases where the guest wants to continuously consume
data from the SVSM (e.g. event-like information). Would it make sense to
have another set of calls to set up a shared ring buffer with a
source-defined entry size? Or 2 separate ring buffers in the case of
read/write sources. This could avoid a lot of calling and copying
overhead between the SVSM and the lower VPML guest. If this adds too
much complexity, it could be gated behind a higher protocol version to
allow for simpler implementations.

Best,
Carlos