2017-04-18 13:11+0200, David Hildenbrand: > 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. This patch wanted to make KVM_MAX_VCPUS just a compatibility option for old userspaces and not looked at in new ones, so we wouldn't have to touch it from now on. >> 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. Good point. I'll cover it in the next email. Thanks.
