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.
> 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?
--
Sasha.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
