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