Re: SVSM Observability and Configuration Protocol draft

Jörg Rödel <[email protected]> Tue, 14 Apr 2026 11:59:40 +0200
Newsgroups dev.linux.lists.coconut-svsm
Message-ID <2qhv4ezvbgww22lowygw647dgcmejfzcjiqhmo2boxh3scybw4@xmzjjbxw3e6p>
Hi Carlos,

On Tue, Apr 14, 2026 at 11:38:44AM +0200, Carlos López wrote:

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

Good idea. The fundamental use-case is to expose the log buffer to the guest
OS. But a lot of others come to mind as well, like memory usage statistics and
more.

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

What use-case(s) do you have in mind that would benefit from that? I have a
future extension in mind where the guest OS can register an IRQ which the SVSM
will send when a given source changes. The use-case would be to push a changed
root-hash of the cocoon-fs storage to the guest OS for logging and checking
purposes to make storage-replay attacks harder.

-Joerg