RE: [EXTERNAL] Re: SVSM Development Call July 2nd, 2025

> OVMF doing svsm calls for this should work fine (didn't actually test, but OVMF does memory validate calls quite early at boot, so I don't expect blockers).  A protocol along these lines should work I think:

There are two challenges with using an SVSM protocol to discover the memory map.  First, at least as I have been led to believe, OVMF isn't able to execute SVSM calls prior to the point in time that it requires the memory map to be available.  More importantly, though, SVSM calls are only available on SEV-SNP architectures, but memory reserves for page bitmaps are required on all platforms that support COCONUT-SVSM (TDX today, and ARM-CCA in the future).  Devising a protocol that only works on one architecture doesn't leave us in a very good place for the future.  Whatever design we produce for TDX should work equally well on SEV-SNP and thus should be our first choice so we can minimize the amount of platform-specific logic.

-Jon 

-----Original Message-----
From: Gerd Hoffmann <[email protected]> 
Sent: Friday, July 11, 2025 6:31 AM
To: Jon Lange <[email protected]>
Cc: Relph, Richard <[email protected]>; Jörg Rödel <[email protected]>; [email protected]; [email protected]
Subject: Re: [EXTERNAL] Re: SVSM Development Call July 2nd, 2025

On Thu, Jul 10, 2025 at 04:32:58AM +0000, Jon Lange wrote:
> > i.e. support for SVSM_CORE_DEPOSIT_MEM ?
> 
> No, the SVSM knows the full memory map at boot time and therefore can 
> know the amount of memory required for all bitmaps as part of its boot 
> flow.  The simplest approach will be for the SVSM to carve out 
> whatever memory it requires, and to tell the guest (OVMF) what memory 
> it has claimed for itself.  There is no need for additional bitmap 
> memory unless the guest support memory ballooning, which I think we 
> can consider out of scope for now.  So the question is what is the 
> best way for the SVSM to advertise its carve-out to OVMF.

OVMF doing svsm calls for this should work fine (didn't actually test, but OVMF does memory validate calls quite early at boot, so I don't expect blockers).  A protocol along these lines should work I think:

memmap call #1

  IN  RAX    $protocol.1
  OUT RCX    number of entries

memmap call #2

  IN  RAX    $protocol.2
  IN  RCX    entry index
  OUT RCX    entry index
  OUT RDX    entry type (e820)
  OUT R8     entry address
  OUT R9     entry size

Comments?

take care,
  Gerd