Re: SVSM Development Call July 2nd, 2025

Jörg Rödel <[email protected]> Fri, 4 Jul 2025 18:39:42 +0200
Newsgroups dev.linux.lists.coconut-svsm,dev.linux.lists.linux-coco
Message-ID <4qbnbdno6hof3llfemhxc4prm7x2vzpqmvjknykelucpqhyryz@kbgpmaoy7vmz>
Hi Gerd,

On Fri, Jul 04, 2025 at 12:36:07PM +0200, Gerd Hoffmann wrote:
> 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.

The idea is that COCONUT provides an IGVM memory map to OVMF, which takes it as
a base for its memory map instead of the E820 from FWCFG.

Longer term it would be great to fully enable OVMF for IGVM, so that it can
also consume some of the ACPI tables from there instead of FWCFG. But that is
future stuff, what we need for now is the memory map.

Regards,

	Joerg