Re: SVSM Development Call July 2nd, 2025

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

On 7/4/2025 11:39 AM, Jörg Rödel wrote:
> 
> 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.

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.

Richard