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

> I see the point in having only one implementation for this instead of
> implementing this again and again for each platform supported.  But
> waiting for Intel until we move forward doesn't look attractive either.

We've discussed this topic in the Technical Steering Committee, and our perspective is that this work is critical but not urgent.  We are not aware of any immediate use cases that would encourage us to create cross-platform divergence just for the sake of getting something built in the short term.  If you are aware of any use cases, please let us know.  I would guess that if we can demonstrate some good reasons to get this done soon, then some volunteers might emerge to help with the cross-platform concerns sooner rather than later, and if not, we can have a good discussion about the right set of compromises.

-Jon

-----Original Message-----
From: Gerd Hoffmann <[email protected]>
Sent: Tuesday, July 15, 2025 8:07 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 Mon, Jul 14, 2025 at 04:18:11PM +0000, Jon Lange wrote:
> > Huh?  I've assumed svsm protocols can work on TDX too.
>
> 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.

Ok, so unclear at this point in time what will happen here.

> 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.

Well, there is the TDX Virtual Firmware Design Guide:
https://cdrdv2-public.intel.com/733585/tdx-virtual-firmware-design-guide-rev-004-20231206.pdf

Section 4.2 "TD Hand-Off Block (HOB)" describes how information can be
passed from VMM to the firmware.  It's about EFI firmware running on TDX
directly, without SVSM, but I think the same should work for launching
EFI firmware under SVSM.

> I know that Intel began investigating this work but I don't know how
> far it's gotten.

This does NOT sound like Intel wants reuse the existing spec.  At the
same time it is totally unclear if and when we get more clarity here
from Intel.

Hmm.

I see the point in having only one implementation for this instead of
implementing this again and again for each platform supported.  But
waiting for Intel until we move forward doesn't look attractive either.

take care,
  Gerd