On 2011-09-04 15:32, Anthony Liguori wrote: > On 09/04/2011 07:13 AM, Jan Kiszka wrote: >> On 2011-09-03 21:54, Anthony Liguori wrote: >>> On 08/31/2011 05:53 AM, Jan Kiszka wrote: >>>> On 2011-08-31 10:25, Peter Maydell wrote: >>>>> On 30 August 2011 20:28, Jan Kiszka<jan.kis...@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. >>> >>> Can you provide some concrete use-cases of this? I'm not convinced this >>> is really all that important and it seems like tremendous amounts of >>> ugliness would be needed to support it. >> >> INTx support for device assignment, vhost, or any other future in-kernel >> IRQ sources. > > I prefer to not think of IRQs as special things. They're just single > bits of information that flow through the device model. Having a higher > level representation that understands something like paths seems wrong > to me. > > I'd prefer to treat things like device assignment as a hack. You just > need code that can walk the device tree to figure out the path (which is > not generic code, it's very machine specific). Then you tell the kernel > the resolution of the path and are otherwise completely oblivious in > userspace.
See it as you like, but we need the support, not only for device assigment. And I do not see any gain it hacking this instead of designing it. Jan
signature.asc
Description: OpenPGP digital signature
