Re: SVSM Development Call July 2nd, 2025

Gerd Hoffmann <[email protected]> Fri, 4 Jul 2025 12:36:07 +0200
Newsgroups dev.linux.lists.coconut-svsm,dev.linux.lists.linux-coco
Message-ID <vpwzlcdbpu3kdshsgfshwfldqm5wtcesblwa7gzwyaf3tgtqwp@2vh37q57z2xe>
On Fri, Jul 04, 2025 at 10:12:03AM +0200, Jörg Rödel wrote:
> Meeting minutes are now posted:
> 
> 	https://github.com/coconut-svsm/governance/pull/65

<quote>
  SVSM deciding its memory needs and informing OVMF. Peter Fang started
  exploring this, but it's not trivial and will take time to establish a
  good protocol for memory consumption and handoff. 
</quote>

What exactly we are talking about?  In the call alot of the discussion
centered around tracking the state of pages, and it wasn't totally clear
whenever that was an independent discussion or not ...

From OVMF perspective I don't see this as a big problem, assuming we are
talking about static allocation.  The memory discovery code is designed
around e820.  Typically OVMF simply loads the e820 table from qemu via
fw_cfg.  But there are multiple ways to get the memory map, when running
on xen or cloud hypervisor things are handled in a different way.
Adding one more option for svsm surely is possible.

So svsm could reserve some memory block for itself, even dynamically
sized (looking at CPUs and memory installed to estimate how much it will
need for page tables etc).  Split the e820 entry where that memory is
taken from into two, one RAM and one RESERVED.  Pass that modified e820
table to OVMF, or provide some svsm protocol so OVMF can query that.

take care,
  Gerd