Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs

[Gleb Natapov]

On Sun, Jun 13, 2010 at 05:34:24PM +0100, Paul Brook wrote:
> > TBH I preferred the original system whereby the source can query the state
> > of the sink (i.e "are you ignoring this line?").  Note that conceptually
> > this should be *querying* state, not responding to an event.
> 
> People are still pushing qemu_irq as an message passing interface, so I'm 
> going to expand a bit more on how I think this could be avoided.
> 
Please, please, please write code and show how it solves existing
problems. Code talks much better then words.

> Start with the assumption that qemu irq represents a single bit of 
> information. The current implementation is stateless, but in principle it 
> could remember its state and ignore redundant calls to qemu_set_irq.
> 
And I don't see why it will affect proposed implementation. Device
should not call qemu_set_irq() with the same state twice anyway. Some
device's implementations are lazy so they don't track previous state, but
this is just implementation detail. 

> In order to workaround the periodic timer issue, we need some way of for the 
> source device to interrogate the target device state relating to this link. 
> The suggestions so far are along the lines of "what happened when I made this 
> change". This makes me unhappy, because it's overlaying event semantics on 
> top 
> of a state based system.
> 
> Instead I suggest that we should be describing what the target state 
> associated with this input is.  Suitable return values could be:
>  * normal: This input effects the state of the target device. Note that this 
> need not imply that changing the input actually effects the output at this 
> time. e.g. if an interrupt controller is already processing a higher priority 
> input, the low priority inputs should still return "normal" - the input will 
> be processed once the unrelated high priority input is finished.
>  * latched: This input has already effected target device state, and will be 
> ignored until reset by some external event. Typically means an interrupt 
> controller latches its inputs, and this input has already been latched.
>  * masked: This input is ignored.
> 
> In practice these should give approximately the same information as event 
> based delivered/coalesced/dropped responses.  The difference is that they are 
> consistent with the state based nature of qemu_irq.
> 
You just described what was proposed by Jan, you just not agree that it
should be done on top of qemu_irq without proposing any alternatives.
The problem is that device doesn't know what its target is and it can have
multiple targets (that is why hack that exist today works only for one
particular configuration as Blue Swirl found out the hard way). qemu_irq
traverses the dynamic chain of links that connects source and its destinations,
and thus device itself doesn't need to know what its destinations are.

--
                        Gleb.