On Mon, 2024-04-08 at 09:20 -0700, Sean Christopherson wrote: > > Another option is that, KVM doesn't allow userspace to configure > > CPUID(0x8000_0008).EAX[7:0]. Instead, it provides a gpaw field in struct > > kvm_tdx_init_vm for userspace to configure directly. > > > > What do you prefer? > > Hmm, neither. I think the best approach is to build on Gerd's series to have KVM > select 4-level vs. 5-level based on the enumerated guest.MAXPHYADDR, not on > host.MAXPHYADDR. So then GPAW would be coded to basically best fit the supported guest.MAXPHYADDR within KVM. QEMU could look at the supported guest.MAXPHYADDR and use matching logic to determine GPAW. Or are you suggesting that KVM should look at the value of CPUID(0X8000_0008).eax[23:16] passed from userspace? I'm not following the code examples involving struct kvm_vcpu. Since TDX configures these at a VM level, there isn't a vcpu. The challenge for TDX with the KVM_GET_SUPPORTED_CPUID/KVM_SET_CPUID language of enumeration/enabling of features, is that not all CPUID leafs are configurable for TDX. Today KVM_SET_CPUID sort of serves two roles. Configuring CPUID values and actually enabling feature virtualization logic. In the current TDX module CPUID 0x8000_0008 is not configurable. So the TDX code in KVM would have to just peak at the value and discard it. If we try to use a KVM_GET_SUPPORTED_CPUID/KVM_SET_CPUID model, then maybe we could clarify things by exposing which leafs are configurable. Then userspace can know which CPUID leafs are information for KVM, and which are actually controlling the result of the CPUID instruction in the TD.
