docs: add overview of mkosi and systemd use - #262
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new documentation landing page intended to capture shared architecture context between sev-certify and the forked sev-performance, focusing on how mkosi-built host/guest images are produced and orchestrated (not step-by-step usage).
Changes:
- Introduces
docs/architecture.mddescribing the mkosi-based image workflow and host/guest relationship. - Documents distribution via GitHub Release Assets and batch-mode orchestration via systemd/journald.
- Adds “where to look next” pointers to related docs (with some references needing adjustment).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| A common pattern is to forward **guest journald** logs to the host so you can inspect guest behavior without needing SSH. | ||
|
|
||
| In perf, see `docs/modules/logging.md` for the implementation details. |
| - Certification/dispatch-style running: `docs/how-to-generate-certs.md` (stub) | ||
| - Manual guest launching (debugging): `docs/how-to-run-guest-manually.md` (stub) |
| - perf-specific guest orchestration: `docs/modules/launch-snp-guest.md` | ||
| - perf-specific containerized workloads: `docs/modules/workload-runner.md` |
|
|
||
| Historically, sev-certify used a “results as GitHub Issues” approach to persist run outputs. | ||
|
|
||
| Perf currently still has related plumbing/code paths, but this is expected to change as: |
|
Overall doc name and scope seems like a good idea to me - though I don't know about having a shared doc w/ sev-performance, I'd think it'd be better to not have references to sev-performance (as that opens a whole other discussion on what that project does, which is imo not necessary to know about). In this arch doc I'd want to link in how sev_verify is run and the various stages (i.e. boot.target -> system.target -> test.target -> stop.target) as well. Also useful to have the diagram about dispatch, beacon, and github relationships (data flow) - I think @DGonzalezVillal had one. Similar points about missing docs in docs/modules, though I assume you'd add that later. |
Agree. It may only ever be a placeholder/reminder that it would be good to have an "architecture" (overview) doc. |
A bit of a placholder for now (and, therefore, a draft), but intended to do what the title says.