From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] x86: Raise the hard VCPU count limit Date: Thu, 14 Jul 2011 11:14:39 +0300 Message-ID: <4E1EA56F.8070305@redhat.com> References: <1310214320-12488-1-git-send-email-levinsasha928@gmail.com> <4E1D9DFF.1090403@redhat.com> <1310587247.28301.2.camel@lappy> 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]:53331 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753909Ab1GNIOu (ORCPT ); Thu, 14 Jul 2011 04:14:50 -0400 In-Reply-To: <1310587247.28301.2.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: On 07/13/2011 11:00 PM, Sasha Levin wrote: > On Wed, 2011-07-13 at 16:30 +0300, Avi Kivity wrote: > > 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? > > > > I'm not sure. I've successfully tried it with 255 vcpus. > Even 255 is problematic. One APIC ID is consumed by the IO-APIC, and ID 255 is reserved for broadcast IIRC. So at most 254 vcpus can be addressed. > > 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; > > } > > > > > > I don't quite understand what KVM_MAX_VCPUS has to do with that if (). > Shouldn't it check whether theres more than one buffer between first and > last? What role does KVM_MAX_VCPUS play there? At most KVM_MAX_VCPUS can be writing simultaneously. Since we're checking outside the spinlock, we have to consider the worst case. -- error compiling committee.c: too many arguments to function