Re: SVSM Development Call July 2nd, 2025

["Relph, Richard" <richard.relph@amd.com>]

On 7/8/2025 9:12 AM, Gerd Hoffmann wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
>   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?

Jon Lange should weigh in here... he's the expert on this.
But I believe it would need to be dynamic at run-time.
Using 'worst case' allocations that might have every page ending up needing it's own page state entry leads to excessive memory reservations. While not having enough memory leads to fatal errors. Being able start with a "reasonable" amount for page state while allowing for expansion later if needed is the preferred solution. At least that's what I was hearing last Wednesday.

Richard

  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
>