Re: [PATCH v2 1/1] x86/tdx: Add __tdcall() and __tdvmcall() helper functions

[Sean Christopherson]

On Thu, Apr 22, 2021, Andi Kleen wrote:
> On Thu, Apr 22, 2021 at 06:21:07PM -0700, Dave Hansen wrote:
> > On 4/22/21 6:09 PM, Kuppuswamy, Sathyanarayanan wrote:
> > > But let me try to explain it here. What I meant by complication is,
> > > for in/out instruction, we use alternative_io() to substitute in/out
> > > instructions with tdg_in()/tdg_out() assembly calls. So we have to ensure
> > > that we don't corrupt registers or stack from the substituted instructions
> > > 
> > > If you check the implementation of tdg_in()/tdg_out(), you will notice
> > > that we have added code to preserve the caller registers. So, if we use
> > > C wrapper for this use case, there is a chance that it might mess
> > > the caller registers or stack.
> > > 
> > >     alternative_io("in" #bwl " %w2, %" #bw "0",            \
> > >             "call tdg_in" #bwl, X86_FEATURE_TDX_GUEST,    \

Has Intel "officially" switched to "tdg" as the acronym for TDX guest?  As much
as I dislike having to juggle "TDX host" vs "TDX guest" concepts, tdx_ vs tdg_
isn't any better IMO.  The latter looks an awful lot like a typo, grepping for
"tdx" to find relevant code will get fail (sometimes), and confusion seems
inevitable as keeping "TDX" out of guest code/comments/documentation will be
nigh impossible.

If we do decide to go with "tdg" for the guest stuff, then _all_ of the guest
stuff, file names included, should use tdg.  Maybe X86_FEATURE_TDX_GUEST could
be left as a breadcrumb for translating TDX->TDG.

> > >             "=a"(value), "d"(port))
> > 
> > Are you saying that calling C functions from inline assembly might
> > corrupt the stack or registers?  Are you suggesting that you simply
> 
> It's possible, but you would need to mark a lot more registers clobbered
> (the x86-64 ABI allows to clobber many registers)
> 
> I don't think the stack would be messed up, but there might be problems
> with writing the correct unwind information (which tends to be tricky)
> 
> Usually it's better to avoid it.

For me, the more important justification is that, if calling from alternative_io,
the input parameters will be in the wrong registers.  The OUT wrapper would be
especially gross as RAX (the value to write) isn't an input param, i.e. shifting
via "ignored" params wouldn't work.

But to Dave's point, that justfication needs to be in the changelog.