From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Date: Tue, 20 Dec 2011 15:32:48 +0000 Subject: Re: [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS Message-Id: <1324395168.22797.25.camel@lappy> List-Id: References: <4EE0273D.5030509@ozlabs.org> <6373C89E-DA45-4F95-941B-818C137A9C41@suse.de> In-Reply-To: <6373C89E-DA45-4F95-941B-818C137A9C41@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: Matt Evans , kvm-ppc@vger.kernel.org, KVM list 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 > > --- > > > > 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. -- Sasha. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS Date: Tue, 20 Dec 2011 17:32:48 +0200 Message-ID: <1324395168.22797.25.camel@lappy> References: <4EE0273D.5030509@ozlabs.org> <6373C89E-DA45-4F95-941B-818C137A9C41@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Matt Evans , kvm-ppc@vger.kernel.org, KVM list To: Alexander Graf Return-path: In-Reply-To: <6373C89E-DA45-4F95-941B-818C137A9C41@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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 > > --- > > > > 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. -- Sasha.