On Tue, Aug 13, 2024 at 03:24:32PM +0800, Binbin Wu wrote:When KVM report CPUIDs to userspace, for the entries that index is
If KVM doesn't indicate which CPU leaf doesn't support subleafs when reporting
On 8/13/2024 11:25 AM, Chao Gao wrote:
On Mon, Aug 12, 2024 at 03:48:05PM -0700, Rick Edgecombe wrote:According to "and use KVM_CPUID_FLAG_SIGNIFCANT_INDEX, which are the
From: Xiaoyao Li <xiaoyao.li@xxxxxxxxx>If we convert KVM_TDX_CPUID_NO_SUBLEAF to 0 when reporting capabilities to
While TDX module reports a set of capabilities/features that it
supports, what KVM currently supports might be a subset of them.
E.g., DEBUG and PERFMON are supported by TDX module but currently not
supported by KVM.
Introduce a new struct kvm_tdx_caps to store KVM's capabilities of TDX.
supported_attrs and suppported_xfam are validated against fixed0/1
values enumerated by TDX module. Configurable CPUID bits derive from TDX
module plus applying KVM's capabilities (KVM_GET_SUPPORTED_CPUID),
i.e., mask off the bits that are configurable in the view of TDX module
but not supported by KVM yet.
KVM_TDX_CPUID_NO_SUBLEAF is the concept from TDX module, switch it to 0
and use KVM_CPUID_FLAG_SIGNIFCANT_INDEX, which are the concept of KVM.
QEMU, QEMU cannot distinguish a CPUID subleaf 0 from a CPUID w/o subleaf.
Does it matter to QEMU?
concept of KVM". IIUC, KVM's ABI uses KVM_CPUID_FLAG_SIGNIFCANT_INDEX
in flags of struct kvm_cpuid_entry2 to distinguish whether the index
is significant.
TDX capabilities, how can QEMU know whether it should set the
KVM_CPUID_FLAG_SIGNIFICANT_INDEX flag for a given CPUID leaf? Or is the
expectation that QEMU can discover that on its own?