Messages in this thread | | | Subject | Re: [RFC v2-fix-v1 1/1] x86/tdx: Add __tdx_module_call() and __tdx_hypercall() helper functions | From | "Kuppuswamy, Sathyanarayanan" <> | Date | Tue, 18 May 2021 23:04:13 -0700 |
| |
Hi Dave,
On 5/18/21 10:58 PM, Kuppuswamy Sathyanarayanan wrote: > Guests communicate with VMMs with hypercalls. Historically, these > are implemented using instructions that are known to cause VMEXITs > like vmcall, vmlaunch, etc. However, with TDX, VMEXITs no longer > expose guest state to the host. This prevents the old hypercall > mechanisms from working. So to communicate with VMM, TDX > specification defines a new instruction called "tdcall". > > In TDX based VM, since VMM is an untrusted entity, a intermediary > layer (TDX module) exists between host and guest to facilitate the > secure communication. And "tdcall" instruction is used by the guest > to request services from TDX module. And a variant of "tdcall" > instruction (with specific arguments as defined by GHCI) is used by > the guest to request services from VMM via the TDX module. > > Implement common helper functions to communicate with the TDX Module > and VMM (using TDCALL instruction). > > __tdx_hypercall() - function can be used to request services from > the VMM. > __tdx_module_call() - function can be used to communicate with the > TDX Module. > > Also define two additional wrappers, tdx_hypercall() and > tdx_hypercall_out_r11() to cover common use cases of > __tdx_hypercall() function. Since each use case of > __tdx_module_call() is different, we don't need such wrappers for it. > > Implement __tdx_module_call() and __tdx_hypercall() helper functions > in assembly. > > Rationale behind choosing to use assembly over inline assembly are, > > 1. Since the number of lines of instructions (with comments) in > __tdx_hypercall() implementation is over 70, using inline assembly > to implement it will make it hard to read. > > 2. Also, since many registers (R8-R15, R[A-D]X)) will be used in > TDCALL operation, if all these registers are included in in-line > assembly constraints, some of the older compilers may not > be able to meet this requirement. > > Also, just like syscalls, not all TDVMCALL/TDCALLs use cases need to > use the same set of argument registers. The implementation here picks > the current worst-case scenario for TDCALL (4 registers). For TDCALLs > with fewer than 4 arguments, there will end up being a few superfluous > (cheap) instructions. But, this approach maximizes code reuse. The > same argument applies to __tdx_hypercall() function as well. > > Current implementation of __tdx_hypercall() includes error handling > (ud2 on failure case) in assembly function instead of doing it in C > wrapper function. The reason behind this choice is, when adding support > for in/out instructions (refer to patch titled "x86/tdx: Handle port > I/O" in this series), we use alternative_io() to substitute in/out > instruction with __tdx_hypercall() calls. So use of C wrappers is not > trivial in this case because the input parameters will be in the wrong > registers and it's tricky to include proper buffer code to make this > happen. > > For registers used by TDCALL instruction, please check TDX GHCI > specification, sec 2.4 and 3. > > https://software.intel.com/content/dam/develop/external/us/en/documents/intel-tdx-guest-hypervisor-communication-interface.pdf > > Originally-by: Sean Christopherson<seanjc@google.com> > Signed-off-by: Kuppuswamy Sathyanarayanan<sathyanarayanan.kuppuswamy@linux.intel.com>
I did send it as in-reply-to message id 3a7c0bba-cc43-e4ba-f7fe-43c8627c2fc2@intel.com (your last reply mail id), but for some reason its not detected as reply to original patch "[RFC v2 05/32] x86/tdx: Add __tdcall() and __tdvmcall() helper functions".
I am not sure whats going on, but please review as reply to original patch.
-- Sathyanarayanan Kuppuswamy Linux Kernel Developer
| |