From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsuCS-0004a5-3S for qemu-devel@nongnu.org; Fri, 06 Jun 2014 09:28:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WsuCM-0002wF-Cd for qemu-devel@nongnu.org; Fri, 06 Jun 2014 09:28:52 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37232 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WsuCM-0002w8-5f for qemu-devel@nongnu.org; Fri, 06 Jun 2014 09:28:46 -0400 Message-ID: <5391C1ED.1010405@suse.de> Date: Fri, 06 Jun 2014 15:28:13 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1402058765-48921-1-git-send-email-agraf@suse.de> <20140606151200.660e3072.cornelia.huck@de.ibm.com> <5391BF0A.3000509@suse.de> <20140606152331.1b72245d.cornelia.huck@de.ibm.com> In-Reply-To: <20140606152331.1b72245d.cornelia.huck@de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] KVM: Fix GSI number space limit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org On 06.06.14 15:23, Cornelia Huck wrote: > On Fri, 06 Jun 2014 15:15:54 +0200 > Alexander Graf wrote: > >> On 06.06.14 15:12, Cornelia Huck wrote: >>> On Fri, 6 Jun 2014 14:46:05 +0200 >>> Alexander Graf wrote: >>> >>>> KVM tells us the number of GSIs it can handle inside the kernel. That value is >>>> basically KVM_MAX_IRQ_ROUTES. However when we try to set the GSI mapping table, >>>> it checks for >>>> >>>> r = -EINVAL; >>>> if (routing.nr >= KVM_MAX_IRQ_ROUTES) >>>> goto out; >>>> >>>> erroring out even when we're only using all of the GSIs. To make sure we never >>>> hit that limit, let's reduce the number of GSIs we get from KVM by one. >>>> >>>> Signed-off-by: Alexander Graf >>>> --- >>>> kvm-all.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/kvm-all.c b/kvm-all.c >>>> index 4e19eff..56a251b 100644 >>>> --- a/kvm-all.c >>>> +++ b/kvm-all.c >>>> @@ -938,7 +938,7 @@ void kvm_init_irq_routing(KVMState *s) >>>> { >>>> int gsi_count, i; >>>> >>>> - gsi_count = kvm_check_extension(s, KVM_CAP_IRQ_ROUTING); >>>> + gsi_count = kvm_check_extension(s, KVM_CAP_IRQ_ROUTING) - 1; >>>> if (gsi_count > 0) { >>>> unsigned int gsi_bits, i; >>>> >>> But gsi_count is already marked as used further down in this function, >>> isn't it? Confused. >> gsi_bits = ALIGN(gsi_count, 32); >> [...] >> for (i = gsi_count; i < gsi_bits; i++) { >> set_gsi(s, i); >> } >> >> So if you take gsi_count = 1024, what happens? >> >> gsi_count = 1024; >> gsi_bits = 1024; >> for (i = 1024; i < 1024; i++) { >> set_gsi(s, i); >> } >> >> At least in my world of C that loop never runs, no? >> > But then kvm_irqchip_get_virq() should never return 1024, shouldn't it? Right, because it returns the virq number which starts at 0. However, to describe all virqs from [0..1023] we need 1024 entries which the kernel errors out on. > > And: > > void kvm_irqchip_add_irq_route(KVMState *s, int irq, int irqchip, int pin) > { > [...] > assert(pin < s->gsi_count); > > would trigger too early with your change, wouldn't it? Not really - with my change we only support 1023 virqs. So the biggest virq number is 1022 which is < 1023 :). Sorry for describing this with actual numbers - I find it easier to grasp when I think in concrete numbers here - this stuff is just really spinning my head :). Alex