From: Anthony Liguori <anthony@codemonkey.ws>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Lucas Meneghel Rodrigues <lmr@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Marcelo Tosatti <mtosatti@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
Blue Swirl <blauwirbel@gmail.com>, Avi Kivity <avi@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path
Date: Sun, 04 Sep 2011 09:37:33 -0500 [thread overview]
Message-ID: <4E638D2D.6060503@codemonkey.ws> (raw)
In-Reply-To: <4E6383CB.3070102@codemonkey.ws>
On 09/04/2011 08:57 AM, Anthony Liguori wrote:
> On 09/04/2011 08:49 AM, Jan Kiszka wrote:
>> On 2011-09-04 15:41, Anthony Liguori wrote:
>>> On 09/04/2011 08:36 AM, Jan Kiszka wrote:
>>> Having some sort of global interrupt routing table is just going to add
>>> a layer of complexity for very little obvious gain.
>>
>> It's not yet decided how the problem is solved. A global interrupt
>> matrix is just one proposal, another option is to extend the pin model
>> in a way that supports routing change notifiers and backward polling.
>
> If that's all you need, then you really just want notification on socket
> changes. Backwards polling can be achieved by just adding state to the
> Pin (which I full heartedly support).
>
> If that's all you're proposing, than I'm entirely happy with it :-)
It's not that simple.
Routing paths can change because of device changes, not just socket changes.
I think you would need an interface for irq routing. Something like:
struct IrqRouter {
Interface parent;
void (*foreach_output)(IrqRouter *obj,
void (*fn)(const char *out, void *opaque),
void *opaque);
void (*foreach_input)(IrqRouter *obj,
void (*fn)(const char *in, void *opaque),
void *opaque);
const char *(*get_mapping)(IrqRouter *obj, const char *in);
};
You could then implement this interface in I440FX or any other
controller where we want to be able to support device passthrough.
Representing endpoints as strings means that you can correlate inputs to
outputs throughout the chain provided that you understand how
inputs/outputs relate to plugs/sockets.
I think this has the property of letting you write reasonably generic
code to discover routing while only having to add complexity to the bare
minimum set of devices to enable device passthrough.
It's basically what I suggested for PCI INTx mapping but a little more
generic as an interface so that it can extend to other types of devices.
Regards,
Anthony Liguori
> I'm happy with that because all of the route detection logic can live
> outside of the devices which at least contains the complexity.
>
> Regards,
>
> Anthony Liguori
next prev parent reply other threads:[~2011-09-04 14:37 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-27 14:16 [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path Jan Kiszka
2011-08-28 7:10 ` Blue Swirl
2011-08-28 9:08 ` Jan Kiszka
2011-08-29 19:25 ` Anthony Liguori
2011-08-29 21:06 ` Jan Kiszka
2011-08-29 21:13 ` Avi Kivity
2011-08-29 21:18 ` Jan Kiszka
2011-08-30 19:19 ` Blue Swirl
2011-08-30 19:28 ` Jan Kiszka
2011-08-30 19:43 ` Blue Swirl
2011-08-31 8:25 ` Peter Maydell
2011-08-31 10:53 ` Jan Kiszka
2011-08-31 17:41 ` Blue Swirl
2011-08-31 18:17 ` Jan Kiszka
2011-08-31 19:44 ` Blue Swirl
2011-09-04 10:33 ` Blue Swirl
2011-09-04 12:25 ` Gleb Natapov
2011-09-03 19:54 ` Anthony Liguori
2011-09-04 12:13 ` Jan Kiszka
2011-09-04 13:32 ` Anthony Liguori
2011-09-04 13:36 ` Jan Kiszka
2011-09-04 13:41 ` Anthony Liguori
2011-09-04 13:49 ` Jan Kiszka
2011-09-04 13:57 ` Anthony Liguori
2011-09-04 14:37 ` Anthony Liguori [this message]
2011-09-04 15:20 ` Blue Swirl
2011-09-04 15:31 ` Anthony Liguori
2011-09-04 15:44 ` Blue Swirl
2011-09-05 10:44 ` Edgar E. Iglesias
2011-09-04 14:12 ` Avi Kivity
2011-09-04 14:43 ` Anthony Liguori
2011-09-04 15:03 ` Avi Kivity
2011-09-04 15:19 ` Anthony Liguori
2011-09-04 15:34 ` Avi Kivity
2011-09-04 15:27 ` Blue Swirl
2011-09-04 12:17 ` Avi Kivity
2011-09-04 12:37 ` Jan Kiszka
2011-09-04 12:43 ` Avi Kivity
2011-09-04 13:38 ` Anthony Liguori
2011-09-04 13:42 ` Jan Kiszka
2011-09-04 13:55 ` Anthony Liguori
2011-09-04 13:35 ` Anthony Liguori
2011-08-31 8:28 ` Avi Kivity
2011-08-31 16:59 ` Blue Swirl
2011-08-31 18:04 ` Edgar E. Iglesias
2011-08-31 18:28 ` Jan Kiszka
2011-09-01 5:58 ` Avi Kivity
2011-09-03 20:07 ` Anthony Liguori
2011-09-03 21:10 ` Blue Swirl
2011-09-03 21:41 ` Anthony Liguori
2011-09-04 9:27 ` Blue Swirl
2011-09-03 19:53 ` Anthony Liguori
2011-09-03 21:01 ` Blue Swirl
2011-09-04 14:49 ` Anthony Liguori
2011-09-05 8:38 ` Edgar E. Iglesias
2011-09-05 8:51 ` Avi Kivity
2011-09-05 9:02 ` Peter Maydell
2011-09-05 9:14 ` Avi Kivity
2011-09-05 9:22 ` Edgar E. Iglesias
2011-09-05 9:28 ` Avi Kivity
2011-09-05 10:47 ` Edgar E. Iglesias
2011-09-05 19:36 ` Blue Swirl
2011-09-06 7:46 ` Avi Kivity
2011-09-01 9:08 ` [Qemu-devel] [PATCH v2] pc: Fix and clean " Jan Kiszka
2011-09-03 8:58 ` Blue Swirl
2011-09-03 11:17 ` Jan Kiszka
2011-09-03 11:37 ` Blue Swirl
2011-09-03 18:14 ` Jan Kiszka
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=4E638D2D.6060503@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=jan.kiszka@web.de \
--cc=kraxel@redhat.com \
--cc=lmr@redhat.com \
--cc=mtosatti@redhat.com \
--cc=peter.maydell@linaro.org \
--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).