From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] x86: Raise the hard VCPU count limit Date: Wed, 13 Jul 2011 16:30:39 +0300 Message-ID: <4E1D9DFF.1090403@redhat.com> References: <1310214320-12488-1-git-send-email-levinsasha928@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Ingo Molnar , Marcelo Tosatti , Pekka Enberg To: Sasha Levin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:29163 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753045Ab1GMNaw (ORCPT ); Wed, 13 Jul 2011 09:30:52 -0400 In-Reply-To: <1310214320-12488-1-git-send-email-levinsasha928@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/09/2011 03:25 PM, Sasha Levin wrote: > The patch raises the hard limit of VCPU count to 1024. > > This will allow developers to easily work on scalability > and will allow users to test high VCPU setups easily without > patching the kernel. > > To prevent possible issues with current setups, KVM_CAP_NR_VCPUS > now returns the recommended VCPU limit (which is still 64) - this > should be a safe value for everybody, while a new KVM_CAP_MAX_VCPUS > returns the hard limit which is now 1024. > Can 1024 vcpus even work without interrupt remapping? Looks like the patch will break coalesced mmio: static int coalesced_mmio_in_range(struct kvm_coalesced_mmio_dev *dev, gpa_t addr, int len) { struct kvm_coalesced_mmio_zone *zone; struct kvm_coalesced_mmio_ring *ring; unsigned avail; int i; /* Are we able to batch it ? */ /* last is the first free entry * check if we don't meet the first used entry * there is always one unused entry in the buffer */ ring = dev->kvm->coalesced_mmio_ring; avail = (ring->first - ring->last - 1) % KVM_COALESCED_MMIO_MAX; if (avail < KVM_MAX_VCPUS) { /* full */ return 0; } -- error compiling committee.c: too many arguments to function