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