[PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS

[PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS

[Matt Evans]

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@ozlabs.org>
---

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
+		break;
+	case KVM_CAP_MAX_VCPUS:
+		r = KVM_MAX_VCPUS;
+		break;
 	default:
 		r = 0;
 		break;
-- 
1.7.0.4

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

[Alexander Graf]

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@ozlabs.org>
> ---
> 
> 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.

Alex

PS: Please always CC kvm@vger when talking about stuff that we want feedback from non-PPC folks on.

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

[Alexander Graf]

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@ozlabs.org>
> ---
> 
> 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.

Alex

PS: Please always CC kvm@vger when talking about stuff that we want feedback from non-PPC folks on.

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

[Sasha Levin]

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@ozlabs.org>
> > ---
> > 
> > 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.

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

[Sasha Levin]

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@ozlabs.org>
> > ---
> > 
> > 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.

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

[Alexander Graf]

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@ozlabs.org>
>>> ---
>>> 
>>> 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

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

[Alexander Graf]

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@ozlabs.org>
>>> ---
>>> 
>>> 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