Re: [PATCH] x86: Raise the hard VCPU count limit

[Avi Kivity <avi@redhat.com>]

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