Re: [PATCH v3 07/12] x86/tdx: Make TDX_HYPERCALL asm similar to TDX_MODULE_CALL

[Huang, Kai]

On Thu, 2023-08-03 at 14:45 +0300, kirill.shutemov@xxxxxxxxxxxxxxx wrote:
> On Thu, Jul 27, 2023 at 11:05:35PM +0000, Huang, Kai wrote:
> > On Thu, 2023-07-27 at 20:10 +0300, kirill.shutemov@xxxxxxxxxxxxxxx wrote:
> > > On Wed, Jul 26, 2023 at 11:25:09PM +1200, Kai Huang wrote:
> > > > 
> > > > Remove the __tdx_hypercall_ret() as __tdx_hypercall() already does so.
> > > 
> > > Hm. So we now update struct on all VMCALLs. Is it a good idea? 
> > > 
> > 
> > Do you mean we "unconditionally save output registers to  the structure", right?
> > 
> > > We give
> > > more control to VMM where it is not needed. 
> > > 
> > 
> > I don't quite follow this.  Can you elaborate?
> > 
> > Do you worry about VMM being malicious and putting malicious values to the
> > registers?
> 
> Yes. Caller of the hypercall may expect that the register is in-only and
> re-use the field for other stuff. And it would work until VMM decide
> otherwise.

I would argue from this way: in TDX_HYPERCALL the guest has shared all registers
to the VMM, thus the caller of hypercall cannot assume those registers is in-
only.

> 
> > > I would rather keep the struct
> > > read-only where possible.
> > > 
> > 
> > We can achieve this if there's a clean way to do, but I don't see that.
> 
> Keep _ret() and non-_ret() versions?

The problem is the assembly needs to always turn on the "\ret" so that the R10
(used as VP.VMCALL leaf return code) can be saved to the structure.  Otherwise
we are not able to return VP.VMCALL leaf return code.

Can you elaborate how to do?