Re: [PATCH v2 5/6] KVM: x86: Track available/dirty register masks as "unsigned long" values

["Huang, Kai" <kai.huang@intel.com>]

On Tue, 2026-04-14 at 08:48 -0700, Sean Christopherson wrote:
> On Mon, Apr 13, 2026, Kai Huang wrote:
> > On Mon, 2026-04-13 at 07:54 -0700, Sean Christopherson wrote:
> > > More importantly, because the TDX-Module *requires* RCX (the GPR that holds the
> > > mask of registers to expose to the VMM) to be hidden on TDVMCALL, KVM *can't*
> > > do any kind of meaningful "available" tracking.  
> > > 
> > 
> > Hmm I think RCX conveys the shared GPRs and VMM can read.  Per "Table 5.323:
> > TDH.VP.ENTER Output Operands Format #5 Definition: On TDCALL(TDG.VP.VMCALL)
> > Following a TD Entry":
> > 
> >   RCX   ...
> > 	Bit(s) Name         Description
> > 
> > 	31:0   PARAMS_MASK  Value as passed into TDCALL(TDG.VP.VMCALL) by
> > 			    the guest TD: indicates which part of the guest
> > 			    TD GPR and XMM state is passed as-is to the
> > VMM 
> > 			    and back. For details, see the description of
> > 			    TDG.VP.VMCALL in 5.5.26.
> 
> The problem is that bit 1 in RCX is required to be '0'.  I.e. the guest *can't*
> expose RCX to the VMM.  From the spec:
> 
>   15:0    GPR Mask Controls the transfer of GPR values:
>   Bit 0:  RAX (must be 0)
>   Bit 1:  RCX (must be 0)
> 
> And the code:
> 
>   api_error_type tdg_vp_vmcall(uint64_t controller_value)
>   {
>     api_error_type retval = TDX_OPERAND_INVALID;
>     tdx_module_local_t* tdx_local_data_ptr = get_local_data();
> 
>     tdvmcall_control_t control = { .raw = controller_value };
> 
>     // Bits 0, 1 and 4 and 63:32 of RCX must be 0
>     if (((control.gpr_select & (uint16_t)(BIT(0) | BIT(1) | BIT(4))) != 0) ||  <==== sadness
>          (control.reserved != 0))
>     {
>         retval = api_error_with_operand_id(TDX_OPERAND_INVALID, OPERAND_ID_RCX);
>         TDX_ERROR("Unsupported bits in GPR_SELECT field = 0x%x\n", control.gpr_select)
>         goto EXIT_FAILURE;
>     }
> 
> Oh, dagnabbit.  The spec also says:
> 
>   The value of RCX itself is always passed to the host VMM.
> 
> and then in code:
> 
>     td_exit_qual.gpr_select = control.gpr_select;
>     td_exit_qual.xmm_select = control.xmm_select;
> 
>     tdx_local_data_ptr->vmm_regs.rcx = td_exit_qual.raw;
> 
>     // RAX is not copied, RCX filled above, start from RDX
> 
> I don't get why TDX requires bit 1 to be 0, but whatever.

Right.  It's a bit confusing unfortunately.  Maybe because they think RCX
has a special purpose and don't want to mix it with other registers.

> 
> So I was wrong, KVM can (and should!) validate the registers coming from the
> guest.  If we want to harden TDX, that's the obvious first step.

And by "harden TDX" you mean to validate the necessary GPRs are indeed
marked as shared in RCX for each GHCI-defined TDVMCALL, but otherwise return
error to TD immediately (basically like what sev_es_validate_vmgexit() does
IIUC)?