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.

Pulling in Xiaoyao's idea about using CPUID...

> > +void ucall_arch_init(struct kvm_vm *vm, gpa_t mmio_gpa)
> > +{
> > +     vm_type = vm->type;
> > +     sync_global_to_guest(vm, vm_type);
>
> It works and it looks simple. But we have the architectural approach to
> test if a guest is TD guest, by checking the CPUID 0x21.
>
> Since checking CPUID 0x21 is not complex, and as a bonus it can help
> test if TDX module behaves correctly for CPUID leaf 0x21, I think we
> should switch to use CPUID 0x21 to check if it is TDX VM in guest code?

Absolutely not.  It will require at least one an extra VM-Exit for TDX and non-TDX
guests alike, and thanks to Intel's wonderful CPUID behavior of having unsupported
leaves return the last supported leaf, the guest would have to check CPUID.0x0 and
then CPUID.0x21 on modern hardware, i.e. would incur two extra VM-Exits.  I don't
care about the performance, but from a debug perspective that's going to be awful,
as what should be a super simple operation will be polluted with unwanted data.

Stop trying to reinvent the wheel and just use a virtual function table.

I've verified the attached patches don't break non-TDX selftests, someone just
needs to test the TDX changes.