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 <[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(-) > > 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
