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

> Huh?  I've assumed svsm protocols can work on TDX too.

The idea of an SVSM protocol might be sensible, but there is no calling convention.  The TDX partitioning model and the SEV-SNP VMPL model have radically different concepts of control flow transfers, so the SVSM calling convention is not easily adapted to TDX.  Intel has never defined such a calling convention.  In the past, they have suggested that such a calling convention is not needed, because the L1 can trap and emulate calls (including TDCALL requests), but I think there is now an understanding that this is not sufficient.  However, I am not aware of any active work to define any type of L1/L2 calling convention.

I also know that for this specific question (memory carveouts), Intel's proposed direction was not to rely on an L1/L2 calling convention, but instead to rely on having the L1 place tables into the address space of OVMF before it begins execution.  This, of course, would work equally well on SEV-SNP or any other model in which an SVSM-type environment can execute before the guest firmware.  I know that Intel began investigating this work but I don't know how far it's gotten.

> Can you clarify what options exist on TDX?
> Pointer to documentation is fine.

Because no L1/L2 calling convention has been defined, there is no documentation I can refer you to.  The best I can suggest is the TDX Module ABI specification (which you can find by searching).  There is also the TDX GHCI specification, but this is designed for guest-to-host interaction, and cannot really be used for L1/L2 calls because L2 TDVMCALL invocations may go directly to the host in some configurations, so there is no way to guarantee that the L1 can observe any requests issued by the L2.

-Jon

-----Original Message-----
From: Gerd Hoffmann <[email protected]>
Sent: Monday, July 14, 2025 3:49 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 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