On Fri, Jul 11, 2025, Xiaoyao Li wrote: > On 7/11/2025 9:05 PM, Sean Christopherson wrote: > > On Fri, Jul 11, 2025, Xiaoyao Li wrote: > > > On 6/26/2025 11:58 PM, Sean Christopherson wrote: > > > > On Wed, Jun 25, 2025, Sean Christopherson wrote: > > > > > On Wed, 11 Jun 2025 12:51:57 +0300, Adrian Hunter wrote: > > > > > > Changes in V4: > > > > > > > > > > > > Drop TDX_FLUSHVP_NOT_DONE change. It will be done separately. > > > > > > Use KVM_BUG_ON() instead of WARN_ON(). > > > > > > Correct kvm_trylock_all_vcpus() return value. > > > > > > > > > > > > Changes in V3: > > > > > > Refer: > > > > > > https://lore.kernel.org/r/aAL4dT1pWG5dDDeo@xxxxxxxxxx > > > > > > > > > > > > [...] > > > > > > > > > > Applied to kvm-x86 vmx, thanks! > > > > > > > > > > [1/1] KVM: TDX: Add sub-ioctl KVM_TDX_TERMINATE_VM > > > > > https://github.com/kvm-x86/linux/commit/111a7311a016 > > > > > > > > Fixed up to address a docs goof[*], new hash: > > > > > > > > https://github.com/kvm-x86/linux/commit/e4775f57ad51 > > > > > > > > [*] https://lore.kernel.org/all/20250626171004.7a1a024b@xxxxxxxxxxxxxxxx > > > > > > Hi Sean, > > > > > > I think it's targeted for v6.17, right? > > > > > > If so, do we need the enumeration for the new TDX ioctl? Yes, the userspace > > > could always try and ignore the failure. But since the ship has not sailed, > > > I would like to report it and hear your opinion. > > > > Bugger, you're right. It's sitting at the top of 'kvm-x86 vmx', so it should be > > easy enough to tack on a capability. > > > > This? > > I'm wondering if we need a TDX centralized enumeration interface, e.g., new > field in struct kvm_tdx_capabilities. I believe there will be more and more > TDX new features, and assigning each a KVM_CAP seems wasteful. Oh, yeah, that's a much better idea. In addition to not polluting KVM_CAP, LOL, and we certainly have the capacity in the structure: __u64 reserved[250]; Sans documentation, something like so? -- diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h index 13da87c05098..70ffe6e8d216 100644 --- a/arch/x86/include/uapi/asm/kvm.h +++ b/arch/x86/include/uapi/asm/kvm.h @@ -963,6 +963,8 @@ struct kvm_tdx_cmd { __u64 hw_error; }; +#define KVM_TDX_CAP_TERMINATE_VM _BITULL(0) + struct kvm_tdx_capabilities { __u64 supported_attrs; __u64 supported_xfam; @@ -972,7 +974,9 @@ struct kvm_tdx_capabilities { __u64 kernel_tdvmcallinfo_1_r12; __u64 user_tdvmcallinfo_1_r12; - __u64 reserved[250]; + __u64 supported_caps; + + __u64 reserved[249]; /* Configurable CPUID bits for userspace */ struct kvm_cpuid2 cpuid; diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c index f4d4fd5cc6e8..783b1046f6c1 100644 --- a/arch/x86/kvm/vmx/tdx.c +++ b/arch/x86/kvm/vmx/tdx.c @@ -189,6 +189,8 @@ static int init_kvm_tdx_caps(const struct tdx_sys_info_td_conf *td_conf, if (!caps->supported_xfam) return -EIO; + caps->supported_caps = KVM_TDX_CAP_TERMINATE_VM; + caps->cpuid.nent = td_conf->num_cpuid_config; caps->user_tdvmcallinfo_1_r11 = -- Aha! And if we squeeze in a patch for 6.16. to zero out the reserved array, we can even avoid adding a capability to enumerate the TDX capability functionality. -- diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c index f4d4fd5cc6e8..9c2997665762 100644 --- a/arch/x86/kvm/vmx/tdx.c +++ b/arch/x86/kvm/vmx/tdx.c @@ -181,6 +181,8 @@ static int init_kvm_tdx_caps(const struct tdx_sys_info_td_conf *td_conf, { int i; + memset(caps->reserved, 0, sizeof(caps->reserved)); + caps->supported_attrs = tdx_get_supported_attrs(td_conf); if (!caps->supported_attrs) return -EIO; --
