Messages in this thread | | | From | Vitaly Kuznetsov <> | Subject | Re: [PATCH RFC] KVM: x86: Drop arbitraty KVM_SOFT_MAX_VCPUS | Date | Thu, 11 Nov 2021 15:38:17 +0100 |
| |
Paolo Bonzini <pbonzini@redhat.com> 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@redhat.com> >> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> > > 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
| |