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.
>
