On Tue, 18 Apr 2017 13:11:55 +0200 David Hildenbrand <david@xxxxxxxxxx> wrote: > On 13.04.2017 22:19, Radim Krčmář wrote: > > The basic idea is to let userspace provide the desired maximal number of > > VCPUs and allocate only necessary memory for them. > > > > The goal is to freeze KVM_MAX_VCPUS at its current level and only increase the > > KVM_MAX_VCPUS might still increase e.g. if hw support for more VCPUs is > comming. > > > new KVM_MAX_CONFIGURABLE_VCPUS, probably directly to INT_MAX/KVM_VCPU_ID, so we > > don't have to worry about it for a while. > > > > PPC should be interested in this as they set KVM_MAX_VCPUS to NR_CPUS > > and probably waste few pages for every guest this way. > > As we just store pointers, this should be a maximum of 4 pages for ppc > (4k pages). Is this really worth yet another VM creation ioctl? Is there > not a nicer way to handle this internally? > > An alternative might be to simply realloc the array when it reaches a > certain size (on VCPU creation, maybe protecting the pointer via rcu). > But not sure if something like that could work. I like that idea better, if it does work (I think it should be doable). If we just double the array size every time we run out of space, we should be able to do this with few reallocations. That has also the advantage of being transparent to user space (other than increased number of vcpus). > > > > > > > Radim Krčmář (4): > > KVM: remove unused __KVM_HAVE_ARCH_VM_ALLOC > > KVM: allocate kvm->vcpus separately > > KVM: add KVM_CREATE_VM2 system ioctl > > KVM: x86: enable configurable MAX_VCPU > > > > Documentation/virtual/kvm/api.txt | 28 +++++++++++++++ > > arch/x86/include/asm/kvm_host.h | 1 + > > arch/x86/kvm/irq_comm.c | 4 +-- > > include/linux/kvm_host.h | 23 +++++------- > > include/uapi/linux/kvm.h | 8 +++++ > > virt/kvm/kvm_main.c | 76 +++++++++++++++++++++++++++++++++------ > > 6 files changed, 114 insertions(+), 26 deletions(-) > > > >
