Re: [EXTERNAL] Re: SVSM Development Call July 2nd, 2025
Gerd Hoffmann <[email protected]> Mon, 14 Jul 2025 12:49:09 +0200
| Newsgroups | dev.linux.lists.coconut-svsm,dev.linux.lists.linux-coco |
|---|---|
| Message-ID | <axljobcnpe6oct5v7edaocroajirywcft5z6lgtnoh3s6tj2r6@cux7zhrgbqnc> |
On Fri, Jul 11, 2025 at 05:24:06PM +0000, Jon Lange wrote: > > 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. This is not correct. Experimental but working patches: * coconut: https://github.com/coconut-svsm/svsm/pull/760 * edk2: https://github.com/kraxel/edk2/commits/devel/svsm-memmap/ > 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. Huh? I've assumed svsm protocols can work on TDX too. The calling convention for guests to call into svsm surely must be different on TDX. But I've expected some similar mechanism could be used ... > Whatever design we produce for TDX Can you clarify what options exist on TDX? Pointer to documentation is fine. thanks, Gerd