On 2011-09-04 15:38, Anthony Liguori wrote: > On 09/04/2011 07:37 AM, Jan Kiszka wrote: >> 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 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). > > It's not mandatory. All you need to be able to do is calculate the APIC > IRQ for a given PCI device interrupt. ...and establish notifies for changes along this line. And allow to update intermediate states on access. > That doesn't mean we need to be > able to do arbitrary interrupt resolution in generic code. We will likely have to solve the same problem on none x86 as well. > > There is potentially tremendous complexity here because you'll have to > bake all interrupt rerouting logic into a declarative API and/or call > into generic code to update routing tables. Given the fact that we > can't even generically refer to a device reliably today, this is would > be a daunting task. > > We're making this all more complicated than it needs to be. We can't discuss the problem away, sorry. Jan