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

Gerd Hoffmann <[email protected]> Fri, 11 Jul 2025 15:30:34 +0200
Newsgroups dev.linux.lists.coconut-svsm,dev.linux.lists.linux-coco
Message-ID <auq7txxlerpwzl542o6rkjams22cy6rb2xoi3f7lbej6u47svi@rto2jldlvxyh>
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