On Fri, May 10, 2024, Kai Huang wrote: > On 10/05/2024 4:35 am, Sean Christopherson wrote: > > KVM x86 limits KVM_MAX_VCPUS to 4096: > > > > config KVM_MAX_NR_VCPUS > > int "Maximum number of vCPUs per KVM guest" > > depends on KVM > > range 1024 4096 > > default 4096 if MAXSMP > > default 1024 > > help > > > > whereas the limitation from TDX is apprarently simply due to TD_PARAMS taking > > a 16-bit unsigned value: > > > > #define TDX_MAX_VCPUS (~(u16)0) > > > > i.e. it will likely be _years_ before TDX's limitation matters, if it ever does. > > And _if_ it becomes a problem, we don't necessarily need to have a different > > _runtime_ limit for TDX, e.g. TDX support could be conditioned on KVM_MAX_NR_VCPUS > > being <= 64k. > > Actually later versions of TDX module (starting from 1.5 AFAICT), the module > has a metadata field to report the maximum vCPUs that the module can support > for all TDX guests. My quick glance at the 1.5 source shows that the limit is still effectively 0xffff, so again, who cares? Assert on 0xffff compile time, and on the reported max at runtime and simply refuse to use a TDX module that has dropped the minimum below 0xffff. > And we only allow the kvm->max_vcpus to be updated if it's a TDX guest in > the vt_vm_enable_cap(). The reason is we want to avoid unnecessary change > for normal VMX guests. That's a frankly ridiculous reason to bury code in TDX. Nothing is _forcing_ userspace to set KVM_CAP_MAX_VCPUS, i.e. there won't be any change to VMX VMs unless userspace _wants_ there to be a change.
