Re: [RFC PATCH 4/4] KVM: TDX: Check KVM exit on KVM_HC_MAP_GPA_RANGE when TD finalize

[Binbin Wu]

On 6/11/2025 9:36 PM, Sean Christopherson wrote:
> On Wed, Jun 11, 2025, Binbin Wu wrote:
> > On 6/11/2025 3:58 AM, Sean Christopherson wrote:
> > > On Tue, Jun 10, 2025, Rick P Edgecombe wrote:
> > > > It seems like the reasoning could be just to shrink the possible configurations
> > > > KVM has to think about, and that we only have the option to do this now before
> > > > the ABI becomes harder to change.
> > > >
> > > > Did you need any QEMU changes as a result of this patch?
> > > >
> > > > Wait, actually I think the patch is wrong, because KVM_CAP_EXIT_HYPERCALL could
> > > > be called again after KVM_TDX_FINALIZE_VM. In which case userspace could get an
> > > > exit unexpectedly. So should we drop this patch?
> > > Yes, drop it.
> > So, when the TDX guest calls MapGPA and KVM finds userspace doesn't opt-in
> > KVM_HC_MAP_GPA_RANGE, just return error to userspace?
> Why can't KVM just do what it already does, and return an error to the guest?
>
> 	if (!user_exit_on_hypercall(vcpu->kvm, KVM_HC_MAP_GPA_RANGE)) {
> 		ret = TDVMCALL_STATUS_INVALID_OPERAND;
> 		goto error;
> 	}
My previous thought was MapGpa is in base GHIC API.
Userspace is required to opt-in KVM_HC_MAP_GPA_RANGE.
If not, it's userspace's responsibility, so I thought exit to userspace with
error may be better.

If return an error code is preferred, now it has a new status code
TDVMCALL_STATUS_SUBFUNC_UNSUPPORTED to use.

Basically, if the MapGpa is not support, either choice will stop VM from
execution. But had a second thought, returning an error code to guest allows
guest to choose to continue or not if MapGpa failed, though I can't
imagine what case it is.