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

Gerd Hoffmann <[email protected]> Tue, 15 Jul 2025 17:07:07 +0200
Newsgroups dev.linux.lists.coconut-svsm,dev.linux.lists.linux-coco
Message-ID <757kuxy36oqteplwd3kussc73w6lqeidbu2rxmzladj3kio7ei@jider3lbnthf>
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