Re: [PATCH v14 21/22] KVM: selftests: Add ucall support for TDX

[Peter Fang <peter.fang@intel.com>]

On Fri, Aug 28, 2026 at 07:18:47AM -0700, Sean Christopherson wrote:
> On Thu, Aug 27, 2026, Peter Fang wrote:
> > On Fri, Aug 28, 2026 at 10:31:14AM +0800, Xiaoyao Li wrote:
> > > > 
> > > > Hmm... This makes me wonder if vm->arch.s_bit below could be replaced
> > > > with the same architectural approach. GPAW is available through
> > > > TDG.VP.INFO or the initial RBX value. This does require a bit more
> > > > plumbing though.
> > > 
> > > I'm afraid not. Because below is host code, and vm->arch.s_bit is not used
> > > in guest code.
> > > 
> > > Or are suggesting something like dropping the
> > > 
> > > 	if (is_tdx_vm(vm)) {
> > > 		ucall_mmio_gpa = UCALL_MMIO_GPA | vm->arch.s_bit;
> > > 		sync_global_to_guest(vm, ucall_mmio_gpa);
> > > 	}
> > > 
> > > entirely and use below hardcoded value instead in guest code?
> > > 
> > > 	UCALL_MMIO_GPA | 1 << (GPAW - 1)
> > 
> > Yeah this is what I meant. Just drop sync_global_to_guest() entirely and
> > do things like a normal TDX guest would.
> 
> Blech.  Every time I come back to this series we're still discussing ucall crud,
> and "doing thing like a normal TDX guest".  Selftests aren't normal guests.
> 
> I know I suggested using the HPET base, but I only did so very begrudgingly as I
> couldn't come up with a better alternative to emulated MMIO, and the end result
> is quite gross.  Not only does the code ignore @mmio_gpa but still obviously use
> emulated MMIO, it requires synchronizing data to the guest because KVM disallows
> "private" MMIO.
> 
>   void ucall_arch_init(struct kvm_vm *vm, gpa_t mmio_gpa)
>   {
>          vm_type = vm->type;
>          sync_global_to_guest(vm, vm_type);
> 
>          if (is_tdx_vm(vm)) {
>                  ucall_mmio_gpa = UCALL_MMIO_GPA | vm->arch.s_bit;
>                  sync_global_to_guest(vm, ucall_mmio_gpa);
>          }
>    }
> 
> Retrieving GPA via TDG.VP.INFO isn't any better, it's still an absurd amount of
> "work" for something that should be trivial.
> 
> Can't we just abuse TDVMCALL_REPORT_FATAL_ERROR?  AFAICT, there's no restriction
> on the data payload, and there's enough space to all but guarantee we'll never get
> a false positive.

Ohh interesting idea to use TDVMCALL_REPORT_FATAL_ERROR to pass through
data. Yeah this looks good to me.

>