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

[Binbin Wu <binbin.wu@linux.intel.com>]

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.