Re: SVSM Observability and Configuration Protocol draft

On 4/14/26 11:59 AM, Jörg Rödel wrote:
>> 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.

I don't have a particular use case in mind, but given the general idea
of the protocol, something like this could be used to have poll-based
notification instead of IRQ-based, if the guest desires so. I guess the
log buffer could already benefit from something like this, as it would
remove the need for the guest to call into the SVSM to check if there is
new available data.

Carlos