KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS
Subsystems (3)
PATCH 1/1 KVM: PPC: Add KVM_CAP_NR_VCPUS and KVM_CAP_MAX_VCPUS
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.
---
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(-)
arch/powerpc/kvm/powerpc.c +15 -0
@@ -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 ;
Signature · 1 line
1.7.0.4
Quoted 24 lines · 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 <[email protected]>---
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(-)arch/powerpc/kvm/powerpc.c +1
-0@@ -245,6 +245,21 @@ int kvm_dev_ioctl_check_extension(long ext) r =2 ;break ;#endif +case KVM_CAP_NR_VCPUS :
arch/powerpc/kvm/powerpc.c int kvm_dev_ioctl_check_extension(long ext) · line 258
Quoted 10 lines
arch/powerpc/kvm/powerpc.c +10
-0+/* +* 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.
Quoted 39 lines · Alexander Graf
Quoted 24 lines · 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 <[email protected]>---
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(-)arch/powerpc/kvm/powerpc.c +1
-0@@ -245,6 +245,21 @@ int kvm_dev_ioctl_check_extension(long ext) r =2 ;break ;#endif +case KVM_CAP_NR_VCPUS :arch/powerpc/kvm/powerpc.c int kvm_dev_ioctl_check_extension(long ext) · line 258
Quoted 10 lines
arch/powerpc/kvm/powerpc.c +10
-0+/* +* 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.
Quoted 1 line
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.
Signature · 1 line
Sasha.
Alexander Graf
AppliedQuoted 44 lines · Sasha Levin
Quoted 39 lines · Alexander Graf
Quoted 24 lines · 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 <[email protected]>---
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(-)arch/powerpc/kvm/powerpc.c +1
-0@@ -245,6 +245,21 @@ int kvm_dev_ioctl_check_extension(long ext) r =2 ;break ;#endif +case KVM_CAP_NR_VCPUS :arch/powerpc/kvm/powerpc.c int kvm_dev_ioctl_check_extension(long ext) · line 258
Quoted 10 lines
arch/powerpc/kvm/powerpc.c +10
-0+/* +* 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.Quoted 1 line
Maybe some really big number makes more sense here.
These two caps are defined pretty well on x86:
Quoted 7 lines
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