On Thu, 2023-07-13 at 11:01 +0200, Peter Zijlstra wrote: > On Thu, Jul 13, 2023 at 08:09:33AM +0000, Huang, Kai wrote: > > On Wed, 2023-07-12 at 19:11 +0200, Peter Zijlstra wrote: > > > On Wed, Jul 12, 2023 at 08:55:21PM +1200, Kai Huang wrote: > > > > @@ -65,6 +104,37 @@ > > > > .endif > > > > > > > > .if \ret > > > > + .if \saved > > > > + /* > > > > + * Restore the structure from stack to saved the output registers > > > > + * > > > > + * In case of VP.ENTER returns due to TDVMCALL, all registers are > > > > + * valid thus no register can be used as spare to restore the > > > > + * structure from the stack (see "TDH.VP.ENTER Output Operands > > > > + * Definition on TDCALL(TDG.VP.VMCALL) Following a TD Entry"). > > > > + * For this case, need to make one register as spare by saving it > > > > + * to the stack and then manually load the structure pointer to > > > > + * the spare register. > > > > + * > > > > + * Note for other TDCALLs/SEAMCALLs there are spare registers > > > > + * thus no need for such hack but just use this for all for now. > > > > + */ > > > > + pushq %rax /* save the TDCALL/SEAMCALL return code */ > > > > + movq 8(%rsp), %rax /* restore the structure pointer */ > > > > + movq %rsi, TDX_MODULE_rsi(%rax) /* save %rsi */ > > > > + movq %rax, %rsi /* use %rsi as structure pointer */ > > > > + popq %rax /* restore the return code */ > > > > + popq %rsi /* pop the structure pointer */ > > > > > > Urgghh... At least for the \host case you can simply pop %rsi, no? > > > VP.ENTER returns with 0 there IIRC. > > > > No VP.ENTER doesn't return 0 for RAX. Firstly, VP.ENTER can return for many > > No, but it *does* return 0 for: RBX,RSI,RDI,R10-R15. > > So for \host you can simply do: > > pop %rsi > mov $0, TDX_MODULE_rsi(%rsi) > > and call it a day. This isn't true for the case that VP.ENTER returns due to a TDVMCALL. In that case RCX contains the bitmap of shared registers, and RBX/RDX/RDI/RSI/R8-R15 contains guest value if the corresponding bit is set in RCX (RBP will be excluded by updating the spec I assume). Or are you suggesting we need to decode RAX to decide whether the VP.ENTER return is due to TDVMCALL vs other reasons, and act differently?
