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

[Edgar E. Iglesias]

On Mon, Sep 05, 2011 at 11:51:01AM +0300, Avi Kivity wrote:
> On 09/05/2011 11:38 AM, Edgar E. Iglesias wrote:
> > >
> > >  We shouldn't really use the term IRQ as it's confusing.  I like the term
> > >  "pin" better because that describes what we're really talking about.
> > >
> > >  qemu_irq is designed oddly today because is represents something that is
> > >  intrinsically state (whether a pin is high or low) with an edge
> > >  notification with the assumption that the state is held somewhere else
> > >  (which is usually true).
> >
> > 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.

I think it is important. Because you need to at least be able to mark the
places were there is state. The cache at the sink sounds more right to me.
An IRQ line, can at the same time have multiple states through its
path between source device and the final sink. Every device that needs to
model state should implement/mark it or maybe connect the the generic caching
sink version and devices that manipulate the level but dont have state,
shouldn't.

> (real hardware can query a line at any time, yes?)

IMO, the "query" is just an upside-down way of thinking of it.

What happens is, you change some state, and the state drives changes through
a logic path towards new state that picks up the updated value etc etc.
Quering is like going (for bus accesses): OK, here's my VGA framebuffer
address, lets do a get back through the bus and see what the CPU wants to
write to this location?

According to the query view, you would add state to the memory regions so
that an MMIO device only gets a xxx_access call, and does a query back to
the core to figure out what's going on. Possible? I'm sure it is. Correct?
who knows. But IMO, a very upside-down way of thinking of it.

Cheers