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