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. > > > 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(-) > -- Thanks, David
