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

[Xiaoyao Li]

On 6/11/2025 10:04 PM, Edgecombe, Rick P wrote:
> On Wed, 2025-06-11 at 22:01 +0800, Xiaoyao Li wrote:
> > > > 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?
> >
> > Because GHCI requires it must be supported. No matter with the old GHCI
> > that only allows <GetTdVmCallInfo> to succeed and the success of
> > <GetTdVmCallInfo> means all the TDVMCALL leafs are support, or the
> > proposed updated GHCI that defines <MapGpa> as one of the base API/leaf,
> > and the base API must be supported by VMM.
> >
> > Binbin wants to honor it.
>
> But KVM doesn't need to support all ways that userspace could meet the GHCI
> spec. If userspace opts-in to the exit, they will meet the spec. If they
> configure KVM differently then they wont, but this is their decision.

I agree with you and Sean. And I'm trying to answer Sean's question on 
behalf of Binbin.

Strictly speaking, KVM can be blamed for some reason. Because it is KVM 
that returns success for <GetTdVmCallInfo> unconditionally when r12 == 0 
 to report that all the (base) leafs are supported.

But I totally agree with KVM cannot guarantee userspace will behave 
correctly. Even with this patch that KVM mandates the userspace to 
enable user exit of KVM_HC_MAP_GPA_RANGE, it's still possible for a 
misbehaved userspace to error to TD guest on KVM_HC_MAP_GPA_RANGE and 
breaks the semantics of successful <GetTdVmCallInfo>.

So I'm with you and Sean.