[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB5276B5986582F9AD11D993618C189@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Wed, 23 Mar 2022 03:35:45 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: "Huang, Kai" <kai.huang@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
CC: "Hansen, Dave" <dave.hansen@...el.com>,
"Christopherson,, Sean" <seanjc@...gle.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"Luck, Tony" <tony.luck@...el.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"Williams, Dan J" <dan.j.williams@...el.com>,
"Yamahata, Isaku" <isaku.yamahata@...el.com>,
"Huang, Kai" <kai.huang@...el.com>
Subject: RE: [PATCH v2 03/21] x86/virt/tdx: Implement the SEAMCALL base
function
> From: Kai Huang <kai.huang@...el.com>
> Sent: Sunday, March 13, 2022 6:50 PM
>
> Secure Arbitration Mode (SEAM) is an extension of VMX architecture. It
> defines a new VMX root operation (SEAM VMX root) and a new VMX non-
> root
> operation (SEAM VMX non-root) which isolate from legacy VMX root and
> VMX
> non-root mode.
s/isolate/are isolated/
>
> A CPU-attested software module (called the 'TDX module') runs in SEAM
> VMX root to manage the crypto protected VMs running in SEAM VMX non-
> root.
> SEAM VMX root is also used to host another CPU-attested software module
> (called the 'P-SEAMLDR') to load and update the TDX module.
>
> Host kernel transits to either the P-SEAMLDR or the TDX module via the
> new SEAMCALL instruction. SEAMCALLs are host-side interface functions
> defined by the P-SEAMLDR and the TDX module around the new SEAMCALL
> instruction. They are similar to a hypercall, except they are made by
"SEAMCALLs are ... functions ... around the new SEAMCALL instruction"
This is confusing. Probably just:
"SEAMCALL functions are defined and handled by the P-SEAMLDR and
the TDX module"
> host kernel to the SEAM software.
>
> SEAMCALLs use an ABI different from the x86-64 system-v ABI. Instead,
> they share the same ABI with the TDCALL. %rax is used to carry both the
> SEAMCALL leaf function number (input) and the completion status code
> (output). Additional GPRs (%rcx, %rdx, %r8->%r11) may be further used
> as both input and output operands in individual leaf SEAMCALLs.
>
> Implement a C function __seamcall() to do SEAMCALL using the assembly
> macro used by __tdx_module_call() (the implementation of TDCALL). The
> only exception not covered here is TDENTER leaf function which takes
> all GPRs and XMM0-XMM15 as both input and output. The caller of TDENTER
> should implement its own logic to call TDENTER directly instead of using
> this function.
>
> SEAMCALL instruction is essentially a VMExit from VMX root to SEAM VMX
> root, and it can fail with VMfailInvalid, for instance, when the SEAM
> software module is not loaded. The C function __seamcall() returns
> TDX_SEAMCALL_VMFAILINVALID, which doesn't conflict with any actual error
> code of SEAMCALLs, to uniquely represent this case.
SEAMCALL is TDX specific, is it? If yes, there is no need to have both
TDX and SEAMCALL in one macro, i.e. above can be SEAMCALL_VMFAILINVALID.
Thanks
Kevin
Powered by blists - more mailing lists