Re: SVSM Observability and Configuration Protocol draft

Gerd Hoffmann <[email protected]> Wed, 22 Apr 2026 11:22:44 +0200
Newsgroups dev.linux.lists.coconut-svsm
Message-ID <[email protected]>
> ## SVSM_OCP_LIST Call
> 
> The call is used to query a list or sub-list of observability and configuration
> sources of the SVSM.

> ### Source entry layout
> 
> One entry in the array is 128 bytes in size and uses the following layout:
> 
> | Offset | Size (Bytes) | Description                         |
> |-------:|-------------:|-------------------------------------|
> | `0x00` | 4            | Flags                               |
> | `0x04` | 124          | Name of the source encoded as UTF-8 |
> 
> The Flags stored in each entry are a bit field stored in little-endian byte
> order. The defined flags are:
> 
> | Bit(s) | Name           | Description                                    |
> |-------:|----------------|------------------------------------------------|
> | 0      | `WRITEABLE`    | The source supports the `SVSM_OCP_WRITE` call. |
> | 31:1   | Reserved – MBZ | All other bits are reserved and must be zero.  |

The SVSM_OCP_READ call allows for arbitrary data being returned.  So I
think it makes sense to include type information in the returned data
structure, and maybe also usage information.

Things coming to mind:

 * u64_value -- integer value (example: number of free pages).
 * u64_count -- integer counter (example: number of page faults).
 * bool
 * str -- variable length string (example: process name).
 * str_once -- variable length string, data will be returned only once
   (i.e. reading data clears it, example: log buffer).
 * sha256 -- hash value (example: cocoonfs root hash).

We might also add the protocol number, so we can tag vtpm sources with
SVSM_VTPM_PROTOCOL, ...

> ## SVSM_OCP_READ Call
> 
> This call reads data from a single observability or configuration source.

Idea #1: Add support for a SVSM_OCP_READ_REGISTER call.  Supports
fixed-size sources with up to 8 bytes in size.  Returns data in a
cpu register instead of a memory buffer (i.e. svsm can skip the guest
page mapping).

Idea #2: Add support for a SVSM_OCP_READ_BATCH call.  Allows reading
multiple sources with a single call.  Maybe also limit to fixed-size
sources.

take care,
  Gerd