All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Avi Kivity <avi@redhat.com>
Cc: Lucas Meneghel Rodrigues <lmr@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Blue Swirl <blauwirbel@gmail.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path
Date: Sun, 04 Sep 2011 14:37:17 +0200	[thread overview]
Message-ID: <4E6370FD.2010703@web.de> (raw)
In-Reply-To: <4E636C72.4080608@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

On 2011-09-04 14:17, Avi Kivity wrote:
> On 08/31/2011 01:53 PM, Jan Kiszka wrote:
>> On 2011-08-31 10:25, Peter Maydell wrote:
>> >  On 30 August 2011 20:28, Jan Kiszka<jan.kiszka@web.de>  wrote:
>> >>  Yes, that's the current state. Once we have bidirectional IRQ
>> links in
>> >>  place (pushing downward, querying upward - required to skip IRQ
>> routers
>> >>  for fast, lockless deliveries), that should change again.
>> >
>> >  Can you elaborate a bit more on this? I don't think anybody has
>> >  proposed links with their own internal state before in the qdev/qom
>> >  discussions...
>>
>> That basic idea is to allow
>>
>> a) a discovery of the currently active IRQ path from source to sink
>>     (that would be possible via QOM just using forward links)
>>
>> b) skip updating the states of IRQ routers in the common case, just
>>     signaling directly the sink from the source (to allow in-kernel IRQ
>>     delivery or to skip taking some device locks). Whenever some router
>>     is queried for its current IRQ line state, it would have to ask the
>>     preceding IRQ source for its state. So we need a backward link.
>>
>> We haven't thought about how this could be implemented in details yet
>> though. Among other things, it heavily depends on the final QOM design.
>>
> 
> Looks like a similar path to the memory API.  A declarative description
> of the interrupt hierarchy allows routes to be precalculated and flattened.
> 
> (here it's strictly an optimization; with the memory API it's a
> requirement since kvm requires a flattened representation, and tcg is
> greatly simplified by it).

With current kvm device assignment it's mandatory as it only support
kernel/kernel IRQ delivery. Only vfio's eventfds will make it optional
(but still highly desirable).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2011-09-04 12: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
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 [this message]
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=4E6370FD.2010703@web.de \
    --to=jan.kiszka@web.de \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=blauwirbel@gmail.com \
    --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 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.