* [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS
@ 2011-12-08 2:55 Matt Evans
2011-12-20 15:17 ` Alexander Graf
0 siblings, 1 reply; 7+ messages in thread
From: Matt Evans @ 2011-12-08 2:55 UTC (permalink / raw)
To: kvm-ppc
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS
2011-12-08 2:55 [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS Matt Evans
@ 2011-12-20 15:17 ` Alexander Graf
0 siblings, 0 replies; 7+ messages in thread
From: Alexander Graf @ 2011-12-20 15:17 UTC (permalink / raw)
To: Matt Evans; +Cc: kvm-ppc, KVM list
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS
@ 2011-12-20 15:17 ` Alexander Graf
0 siblings, 0 replies; 7+ messages in thread
From: Alexander Graf @ 2011-12-20 15:17 UTC (permalink / raw)
To: Matt Evans; +Cc: kvm-ppc, KVM list
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS
2011-12-20 15:17 ` Alexander Graf
@ 2011-12-20 15:32 ` Sasha Levin
-1 siblings, 0 replies; 7+ messages in thread
From: Sasha Levin @ 2011-12-20 15:32 UTC (permalink / raw)
To: Alexander Graf; +Cc: Matt Evans, kvm-ppc, 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 <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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS
@ 2011-12-20 15:32 ` Sasha Levin
0 siblings, 0 replies; 7+ messages in thread
From: Sasha Levin @ 2011-12-20 15:32 UTC (permalink / raw)
To: Alexander Graf; +Cc: Matt Evans, kvm-ppc, 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 <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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS
2011-12-20 15:32 ` Sasha Levin
@ 2011-12-20 15:45 ` Alexander Graf
-1 siblings, 0 replies; 7+ messages in thread
From: Alexander Graf @ 2011-12-20 15:45 UTC (permalink / raw)
To: Sasha Levin; +Cc: Matt Evans, kvm-ppc, KVM list
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS
@ 2011-12-20 15:45 ` Alexander Graf
0 siblings, 0 replies; 7+ messages in thread
From: Alexander Graf @ 2011-12-20 15:45 UTC (permalink / raw)
To: Sasha Levin; +Cc: Matt Evans, kvm-ppc, KVM list
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-12-20 15:45 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-08 2:55 [PATCH] KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS Matt Evans
2011-12-20 15:17 ` Alexander Graf
2011-12-20 15:17 ` Alexander Graf
2011-12-20 15:32 ` Sasha Levin
2011-12-20 15:32 ` Sasha Levin
2011-12-20 15:45 ` Alexander Graf
2011-12-20 15:45 ` Alexander Graf
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.