On Mon, 2024-09-30 at 14:26 +0800, Xiaoyao Li wrote: > This patch lacks the documentation of KVM_TDX_GET_CPUID to describe what > it returns and how the returned data is used or expected to be used by > userspace. Yes, we should add some docs. > > Set aside the filtering of KVM's support CPUID bits, KVM_TDX_GET_CPUID > only returns the CPUID leaves that can be readable by TDX module (in > tdx_mask_cpuid()). So what about the leaves that aren't readable? e.g., > CPUID leaf 6,9,0xc,etc, and leaf 0x40000000 and 0x40000001. Hmm. The purpose of this is to IOCTL is to read the values that the TDX module knows about so it can set the values KVM knows about. So I think we should just let it read straight from the TDX module. > > Should userspace to intercept it as the leaves that aren't covered by > KVM_TDX_GET_CPUID are totally controlled by userspace itself and it's > userspace's responsibility to set a sane and valid value? Not sure what you mean by "userspace to intercept it". But letting userspace be responsible to "set a sane and valid value" seems consistent with general KVM philosophy, and how we are planning to handle the issues around the TDX fixed bits. Can you elaborate? And on the consequences from QEMU's side?
