On Tue, Jun 10, 2025, Rick P Edgecombe wrote:
On Tue, 2025-06-10 at 10:14 +0800, Binbin Wu wrote:+1. We do need to be careful about unintentionally creating ABI, but generally
Check userspace has enabled KVM exit on KVM_HC_MAP_GPA_RANGE duringDo we need this change? It seems reasonable, but I don't think we need KVM to
KVM_TDX_FINALIZE_VM.
TDVMCALL_MAP_GPA is one of the GHCI base TDVMCALLs, so it must be
implemented by VMM to support TDX guests. KVM converts TDVMCALL_MAP_GPA
to KVM_HC_MAP_GPA_RANGE, which requires userspace to enable
KVM_CAP_EXIT_HYPERCALL with KVM_HC_MAP_GPA_RANGE bit set. Check it when
userspace requests KVM_TDX_FINALIZE_VM, so that there is no need to check
it during TDX guests running.
Signed-off-by: Binbin Wu <binbin.wu@xxxxxxxxxxxxxxx>
ensure that userspace creates a TD that meets the GHCI spec.
speaking KVM shouldn't police userspace.
So, when the TDX guest calls MapGPA and KVM finds userspace doesn't opt-inSo I'm not sure about the justification.Yes, drop it.
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?