On Wed, Nov 23, 2022 at 12:00:47PM +0200, Zhi Wang <zhi.wang.linux@xxxxxxxxx> wrote: > On Sat, 29 Oct 2022 23:22:12 -0700 > isaku.yamahata@xxxxxxxxx wrote: > > > From: Isaku Yamahata <isaku.yamahata@xxxxxxxxx> > > > > A VMM interacts with the TDX module using a new instruction > > (SEAMCALL). A TDX VMM uses SEAMCALLs where a VMX VMM would have > > directly interacted with VMX instructions. For instance, a TDX VMM > > does not have full access to the VM control structure corresponding > > to VMX VMCS. Instead, a VMM induces the TDX module to act on behalf > > via SEAMCALLs. > > > > Export __seamcall and define C wrapper functions for SEAMCALLs for > > readability. Some SEAMCALL APIs donates pages to TDX module or guest > > TD. The pages are encrypted with TDX private host key id set in high > > It seems a little bit confusing here. > > I guess you are talking about the host pages donated to TDX module will > be encrypted with TDX module global key id, which is used to > encrypted the pages only used by TDX module. For pages donated to the > TD guest, the pages are encrypted with TD guest prviate key id? Basically yes. Only TDR is encrypted with the global key id. > It might be better that you can talk about the actual reaason instead of > the key id stuff. For example Some SEMCALL APIs will zap or write the > pages donated by VMM via MOVDIR64B, which requires the VMM to flush the > cachelines. How about the followings? Some SEAMCALL APIs donates host pages to TDX module or guest TD and the donated pages are encrypted. Some of such SEAMCALLs flush cache lines (typically by movdir64b instruction), some don't. Those that doesn't clear cache lines require the VMM to flush the cache lines to avoid cache line alias. -- Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
