Re: [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20.12.2011, at 16:32, Sasha Levin wrote:

> On Tue, 2011-12-20 at 16:17 +0100, Alexander Graf wrote:
>> On 08.12.2011, at 03:55, Matt Evans wrote:
>> 
>>> PPC KVM lacks these two capabilities, and as such a userland system must assume
>>> a max of 4 VCPUs (following api.txt).  With these, a userland can determine
>>> a more realistic limit.
>>> 
>>> Signed-off-by: Matt Evans <matt@xxxxxxxxxx>
>>> ---
>>> 
>>> Alex: For when you're back in civilisation -- the kvmtool/PPC stuff will be
>>> limited to 4 VCPUs until the kernel returns something for these caps.
>>> 
>>> Cheers, Matt
>>> 
>>> arch/powerpc/kvm/powerpc.c |   15 +++++++++++++++
>>> 1 files changed, 15 insertions(+), 0 deletions(-)
>>> 
>>> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
>>> index 7c7220c..3f7219d 100644
>>> --- a/arch/powerpc/kvm/powerpc.c
>>> +++ b/arch/powerpc/kvm/powerpc.c
>>> @@ -245,6 +245,21 @@ int kvm_dev_ioctl_check_extension(long ext)
>>> 			r = 2;
>>> 		break;
>>> #endif
>>> +	case KVM_CAP_NR_VCPUS:
>>> +		/*
>>> +		 * Recommending a number of CPUs is somewhat arbitrary; we return the number of present
>>> +		 * CPUs for -HV (since a host will have secondary threads "offline"), and for other KVM
>>> +		 * implementations just count online CPUs.
>>> +		 */
>>> +#ifdef CONFIG_KVM_BOOK3S_64_HV
>>> +		r = num_present_cpus();
>>> +#else
>>> +		r = num_online_cpus();
>>> +#endif
>> 
>> That will essentially restrict us to not allow overcommitting when in the scope of a single VM. Is that what we want? You could easily run a 32-way guest on a 4-way host, even with _HV.
>> 
>> Maybe some really big number makes more sense here.
> 
> These two caps are defined pretty well on x86:
> 
> KVM_CAP_MAX_VCPUS - Absolute possible number of vcpus we can squeeze in
> a single guest due to some technical limitation. On x86 it's limited to
> 254 due to not supporting IRQ remapping.
> 
> KVM_CAP_NR_VCPUS - This is actually an arbitrary number which reflects
> the point at which adding more vcpus over this number will actually
> cause a performance hit.

Ah cool - then it's all fine and shiny. Thanks for the reminder! :)

Applied the patch to kvm-ppc-next (with 80 character line limit fixed).

Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux