All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolai Stange <nstange@suse.de>
To: "Jörg Rödel" <joro@8bytes.org>
Cc: coconut-svsm@lists.linux.dev,  Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: SVSM Observability and Configuration Protocol draft
Date: Tue, 14 Apr 2026 10:46:33 +0200	[thread overview]
Message-ID: <87mrz6lyja.fsf@> (raw)
In-Reply-To: <d3v2ljpmhjukdwnavsn436fkgtuuojkptdr3f7bh3fcqr5zayy@d7jhqsyibycw> ("Jörg Rödel"'s message of "Tue, 14 Apr 2026 10:25:31 +0200")

Hi,

Jörg Rödel <joro@8bytes.org> writes:

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

Just a generic comment: as in my understanding there's no central
authority managing the names, would it perhaps make sense to split the
Name from above into something like a 16 byte UUID + a human readable
name, the latter being only informative (or, alternatively, whose
semantics are defined only within the scope of the UUID)?


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

<snip>

>
> ## SVSM_OCP_WRITE Call
>
> This call will attempt to write data into a specified observability or
> configuration source.
>
> ### Registers
>
> | Register | Size (Bytes) | Alignment | In/Out | Description                                        |
> |----------|-------------:|----------:|:------:|----------------------------------------------------|
> | `RAX`    | 4            |           | OUT    | Result value                                       |
> | `RCX`    | 4            |           | IN     | Array index of the source to write to              |
> | `RDX`    | 8            | 8         | IN     | GPA of buffer with data to write                   |
> | `R8 `    | 4            |           | IN     | Number of bytes to write                           |
> | `R8`     | 4            |           | OUT    | Number of bytes written                            |
> | `R9`     | 4            |           | IN     | Byte offset into data to start the write operation |
>
> The `SVSM_OCP_WRITE` call attempts to write data from the GPA specified in
> `RDX` to the observability or configuration source specified in `RCX`. The size
> of the data to write is specified in `R8` and the offset to write the data to
> in `R9`.
>
> Sources can only be written to if the Flags field in the `SVSM_OCP_LIST` call
> has the `WRITEABLE` bit set. If the source is not writable the call will return
> `SVSM_ERR_INVALID_PARAMETER`.
>
> The format of the data allowed to write is source dependent. If a given data
> format is not understood by the source the call will also return
> `SVSM_ERR_INVALID_PARAMETER`.

I assume other errors would be allowed as well? I'm thinking of a
situation where a "source/configuration" is backed by storage, and
writes to that could fail.

Thanks,

Nicolai

-- 
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nürnberg)

  reply	other threads:[~2026-04-14  8:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14  8:25 SVSM Observability and Configuration Protocol draft Jörg Rödel
2026-04-14  8:46 ` Nicolai Stange [this message]
2026-04-14  9:07   ` Jörg Rödel
2026-04-14  9:38 ` Carlos López
2026-04-14  9:59   ` Jörg Rödel
2026-04-14 10:18     ` Carlos López
2026-04-22  9:22 ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mrz6lyja.fsf@ \
    --to=nstange@suse.de \
    --cc=coconut-svsm@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kraxel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.