On Thu, May 30, 2024, Kai Huang wrote: > On Wed, 2024-05-29 at 16:15 -0700, Sean Christopherson wrote: > > In the unlikely event there is a legitimate reason for max_vcpus_per_td being > > less than KVM's minimum, then we can update KVM's minimum as needed. But AFAICT, > > that's purely theoretical at this point, i.e. this is all much ado about nothing. > > I am afraid we already have a legitimate case: TD partitioning. Isaku > told me the 'max_vcpus_per_td' is lowed to 512 for the modules with TD > partitioning supported. And again this is static, i.e., doesn't require > TD partitioning to be opt-in to low to 512. So what's Intel's plan for use cases that creates TDs with >512 vCPUs? > So AFAICT this isn't a theoretical thing now. > > Also, I want to say I was wrong about "MAX_VCPUS" in the TD_PARAMS is part > of attestation. It is not. TDREPORT dosen't include the "MAX_VCPUS", and > it is not involved in the calculation of the measurement of the guest. > > Given "MAX_VCPUS" is not part of attestation, I think there's no need to > allow user to change kvm->max_vcpus by enabling KVM_ENABLE_CAP ioctl() for > KVM_CAP_MAX_VCPUS. Sure, but KVM would still need to advertise the reduced value for KVM_CAP_MAX_VCPUS when queried via KVM_CHECK_EXTENSION. And userspace needs to be conditioned to do a VM-scoped check, not a system-scoped check. > So we could just once for all adjust kvm->max_vcpus for TDX in the > tdx_vm_init() for TDX guest: > > kvm->max_vcpus = min(kvm->max_vcpus, tdx_info->max_vcpus_per_td); > > AFAICT no other change is needed. > > And in KVM_TDX_VM_INIT (where TDH.MNG.INIT is done) we can just use kvm- > >max_vcpus to fill the "MAX_VCPUS" in TD_PARAMS.
