Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path

[Peter Maydell <peter.maydell@linaro.org>]

On 5 September 2011 09:51, Avi Kivity <avi@redhat.com> wrote:
> On 09/05/2011 11:38 AM, Edgar E. Iglesias wrote:
>> I don't agree. That's not what qemu_irq represents.
>> It represents a wire, a mechanism to drive changes through logic paths
>> between state. It is intrinsically stateless.
>>
>> It may be the case that it is missused in some places, or that it isn't
>> always the best thing to use to represent what ever you need to represent,
>> so that you want to complement with other mechanisms.
>> But universally replacing it with a stateful alternative seems wrong to
>> me.

> I agree that qemu_irq is inherently stateless.  But I do think there should
> be a way for the sink to query the line level.  Whether it is implemented as
> a cache of the last qemu_set() level, or with callbacks that query the
> underlying state is not important, but we can't just rely on edge triggers.
>
> (real hardware can query a line at any time, yes?)

There are often significant constraints (eg "can only query at a clock
edge", or "not guaranteed to be valid until some other signal has been
high for at least this time"), which often means hardware will latch
the input value internally. Obviously QEMU doesn't have to care about
things to that level of detail. The reason we don't care is that we're
really restricting ourselves to providing a programmer-visible approximation
to the device behaviour. So I think the right question to ask about qemu_irq
semantics is not "does this act like hardware?" but "what is the right
interface between two components to let us conveniently implement the
behaviour we need?" This probably means that sometimes we want a line
with state-querying and sometimes not.

Ideally our device/object model ought to (a) let us model either option
easily (b) let us easily upgrade a "no state querying" line to a "state
querying" line by having the latter's interface be a superset of the
former's.

[IMHO the most important reason not to call it a qemu_irq is that
'irq' is a description of what the signal is used for, not of its
behaviour. 'gpio' is a bit more neutral.]

-- PMM