From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: Pekka Enberg <penberg@kernel.org>,
mingo@elte.hu, asias.hejun@gmail.com, prasadjoshi124@gmail.com,
kvm@vger.kernel.org
Subject: Re: [PATCH 1/2] kvm tools: Fix IRQ assignments
Date: Fri, 06 May 2011 11:47:42 +0400 [thread overview]
Message-ID: <4DC3A79E.3090406@gmail.com> (raw)
In-Reply-To: <1304667363.10534.5.camel@lappy>
On 05/06/2011 11:36 AM, Sasha Levin wrote:
> On Fri, 2011-05-06 at 10:29 +0300, Pekka Enberg wrote:
>> On Fri, May 6, 2011 at 10:26 AM, Sasha Levin <levinsasha928@gmail.com> wrote:
>>> virtio-blk needs a block of 4 IRQs (currently - staticly defined).
>>> Giving the initial IRQ of 15 causes breakage when adding more
>>> than one device.
>>>
>>> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
>>
>> Can we make the allocation dynamic instead? AFAICT, it could be a simple as
>>
>> int kvm__request_irq(struct kvm *kvm)
>> {
>> return kvm->next_irq++;
>> }
>>
>> that's done at device init time and then we'd just add "int irq" to
>> the individual struct devices.
>>
>> Pekka
>
> afaik, we need to have same IRQ pins for devices which may have
> different IRQ lines (All virtio-blk share same IRQ pin but different
> line, I assume it'll be same with different virtio devices).
>
> So mptable has to manage association between device type and the
> corresponding IRQ pin/line assignment, So dynamic assignment will be
> more of a call with device type and return IRQ pin + line - which makes
> it more complex than just allocating next free IRQ line.
>
Nod, making it dynamic force us to implement some kind of collector for
pci devices, so that it would know pin/vector pair for every device. So
in device init time we need to call kinda mptable_request_irq_pin()
where we could "hint" allocator which pin and irq we need, and say "exclusive"
flag which would tell allocator to fail if irq/pin already borrowed.
The "hints" for every device might left hardcoded in some enum, for other
irqs we might need pure dynamic vector allocator.
--
Thanks,
Cyrill
next prev parent reply other threads:[~2011-05-06 7:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-06 7:26 [PATCH 1/2] kvm tools: Fix IRQ assignments Sasha Levin
2011-05-06 7:26 ` [PATCH 2/2] kvm tools: Simplify search for root device Sasha Levin
2011-05-07 8:41 ` Pekka Enberg
2011-05-07 8:46 ` Sasha Levin
2011-05-07 8:49 ` Prasad Joshi
2011-05-06 7:29 ` [PATCH 1/2] kvm tools: Fix IRQ assignments Pekka Enberg
2011-05-06 7:31 ` Cyrill Gorcunov
2011-05-06 7:36 ` Sasha Levin
2011-05-06 7:43 ` Pekka Enberg
2011-05-06 8:01 ` Sasha Levin
2011-05-06 8:04 ` Pekka Enberg
2011-05-06 8:08 ` Cyrill Gorcunov
2011-05-06 8:10 ` Pekka Enberg
2011-05-06 8:16 ` Cyrill Gorcunov
2011-05-06 7:47 ` Cyrill Gorcunov [this message]
2011-05-06 7:59 ` Pekka Enberg
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=4DC3A79E.3090406@gmail.com \
--to=gorcunov@gmail.com \
--cc=asias.hejun@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--cc=mingo@elte.hu \
--cc=penberg@kernel.org \
--cc=prasadjoshi124@gmail.com \
/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.