Re: SVSM Development Call July 2nd, 2025

  Hi,

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

Should be easy on the edk2 side.  As mentioned the infrastructure to use
different sources for the memory map is already there.  Also OVMF must
do SVSM calls quite early to accept memory, so doing SVSM calls to get
the map is no problem too.

The interface should be usable without allocating memory, for example a
protocol which returns one entry per call so OVMF can loop over the
entries using the stack only should do the trick.

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

ACPI is a bit more tricky because today the process is that OVMF goes
setup the hardware, then qemu goes generate ACPI tables matching the
setup, finally OVMF loads them from qemu.

But as far I know svsm does not want enter the hardware initialization
business, so fetching the tables in svsm instead is not going to work.

> As I heard it, the concern is that maintaining page state in SVSM (not OVMF)
> will eventually require SVSM to have access to a dynamic amount of memory.
> Right now, AFAIK, SVSM has no way to request memory from either the host or the 
> guest.

I assume you mean dynamic at boot time?  i.e. instead of the fixed, 16M
allocation via RequiredMemory IGVM directive svsm estimates how much
it'll need and takes the required chunk of memory from guest RAM?

Once OVMF gets the memory map from svsm not qemu this should be doable,
svsm can simply mark it's own memory as reserved then.

take care,
  Gerd