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
next prev parent reply other threads:[~2014-06-06 13:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 12:46 [Qemu-devel] [PATCH] KVM: Fix GSI number space limit Alexander Graf
2014-06-06 13:12 ` Cornelia Huck
2014-06-06 13:15 ` Alexander Graf
2014-06-06 13:23 ` Cornelia Huck
2014-06-06 13:28 ` Alexander Graf [this message]
2014-06-06 13:41 ` Cornelia Huck
2014-06-06 16:31 ` Paolo Bonzini
2014-06-07 0:31 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).