Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > On 11/11/21 14:47, Vitaly Kuznetsov wrote: >> KVM_CAP_NR_VCPUS is used to get the "recommended" maximum number of >> VCPUs and arm64/mips/riscv report num_online_cpus(). Powerpc reports >> either num_online_cpus() or num_present_cpus(), s390 has multiple >> constants depending on hardware features. On x86, KVM reports an >> arbitrary value of '710' which is supposed to be the maximum tested >> value but it's possible to test all KVM_MAX_VCPUS even when there are >> less physical CPUs available. >> >> Drop the arbitrary '710' value and return num_online_cpus() on x86 as >> well. The recommendation will match other architectures and will mean >> 'no CPU overcommit'. >> >> For reference, QEMU only queries KVM_CAP_NR_VCPUS to print a warning >> when the requested vCPU number exceeds it. The static limit of '710' >> is quite weird as smaller systems with just a few physical CPUs should >> certainly "recommend" less. >> >> Suggested-by: Eduardo Habkost <ehabkost@xxxxxxxxxx> >> Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> > > Yes, this is a good idea. We cannot move it entirely to common code due > to POWER's handling of secondary threads in hypervisors; still, this is > as close as we can get to a common idea of what KVM_CAP_NR_VCPUS means. > S390's idea is also different and while I don't understand at all all these hardware features, KVM_CAP_NR_VCPUS == KVM_CAP_MAX_VCPUS (afaict). This was the first reason to keep KVM_CAP_NR_VCPUS handling in arch specific code. -- Vitaly