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

[Blue Swirl]

On Sun, Jun 13, 2010 at 4:34 PM, Paul Brook <address@hidden> 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.
>
> 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.
>
> 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.

I agree this would be enough for the current RTC/APIC case.

This doesn't help in EOI handling or message passing in any way, but
we can make completely separate systems for those later when the need
arises.