All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH] KVM: Fix GSI number space limit
Date: Fri, 06 Jun 2014 15:28:13 +0200	[thread overview]
Message-ID: <5391C1ED.1010405@suse.de> (raw)
In-Reply-To: <20140606152331.1b72245d.cornelia.huck@de.ibm.com>


On 06.06.14 15:23, Cornelia Huck wrote:
> On Fri, 06 Jun 2014 15:15:54 +0200
> Alexander Graf <agraf@suse.de> wrote:
>
>> On 06.06.14 15:12, Cornelia Huck wrote:
>>> On Fri,  6 Jun 2014 14:46:05 +0200
>>> Alexander Graf <agraf@suse.de> 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 <agraf@suse.de>
>>>> ---
>>>>    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


WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH] KVM: Fix GSI number space limit
Date: Fri, 06 Jun 2014 15:28:13 +0200	[thread overview]
Message-ID: <5391C1ED.1010405@suse.de> (raw)
In-Reply-To: <20140606152331.1b72245d.cornelia.huck@de.ibm.com>


On 06.06.14 15:23, Cornelia Huck wrote:
> On Fri, 06 Jun 2014 15:15:54 +0200
> Alexander Graf <agraf@suse.de> wrote:
>
>> On 06.06.14 15:12, Cornelia Huck wrote:
>>> On Fri,  6 Jun 2014 14:46:05 +0200
>>> Alexander Graf <agraf@suse.de> 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 <agraf@suse.de>
>>>> ---
>>>>    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

  reply	other threads:[~2014-06-06 13:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-06 12:46 [PATCH] KVM: Fix GSI number space limit Alexander Graf
2014-06-06 12:46 ` [Qemu-devel] " Alexander Graf
2014-06-06 13:12 ` Cornelia Huck
2014-06-06 13:12   ` Cornelia Huck
2014-06-06 13:15   ` Alexander Graf
2014-06-06 13:15     ` Alexander Graf
2014-06-06 13:23     ` Cornelia Huck
2014-06-06 13:23       ` Cornelia Huck
2014-06-06 13:28       ` Alexander Graf [this message]
2014-06-06 13:28         ` Alexander Graf
2014-06-06 13:41         ` Cornelia Huck
2014-06-06 13:41           ` Cornelia Huck
2014-06-06 16:31 ` Paolo Bonzini
2014-06-06 16:31   ` [Qemu-devel] " Paolo Bonzini
2014-06-07  0:31   ` Alexander Graf
2014-06-07  0:31     ` [Qemu-devel] " Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5391C1ED.1010405@suse.de \
    --to=agraf@suse.de \
    --cc=cornelia.huck@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.