Re: IRQ handling (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...)

[J. Mayer]

On Sun, 2007-04-08 at 15:41 +0100, Thiemo Seufer wrote:
> J. Mayer wrote:
> > On Sun, 2007-04-08 at 01:04 +0100, Thiemo Seufer wrote:
> > > J. Mayer wrote:
> > > [snip]
> > > > To give you an real example why arbitrary limits are not acceptable AT
> > > > ALL: I know an embedded Mips device (widely used !) with 2 CPU, 8 PIC
> > > > and about 500 IRQ sources.
> > > 
> > > Care to tell which one this is?
> > 
> > I'm sorry, I'm no sure I can (NDA rules....).
> > Let's say it's a chips used in some consumer electronics products.
> > 
> > > > How can you even pretend add a limited
> > > > structure in the CPUState structure when this is exactly the kind of
> > > > device some people want to emulate in Qemu ? Your concept is completely
> > > > broken, you have to admit it. You can never put peripheral informations
> > > > in the CPUState structure.
> > > 
> > > At least for MIPS it makes sense to put the CPU-internal controller
> > > in exactly that place.

For the internal IRQ controller, OK. For the external ones, it makes no
sense to put any informations about them into the CPU.

> > It does not. If you look well, the IRQ controller is not in the CPU.
> > Only the exception are managed in the CPU. The "internal" IRQ controller
> > is a peripheral device located in the CP0.
> 
> It is not a peripheral but an integral part of any MIPS-compatible CPU.
> The architecture allows since MIPS{32,64}R2 to optionally externalize
> interupts (the so-called VEIC mode), but even those devices have to
> implement the traditional "compatibility mode" interrupt handling.
> 
> This is spelt out e.g. in MD00091, page 32, as available from
> http://www.mips.com/products/resource_library/product_materials/

> > OK, the CP0 is tightly
> > coupled to the CPU so it's easier to consider it as part of the CPU,
> > when emulating it. But it seems like you could imagine a MIPS CPU
> > without a CP0 coprocessor (even if it will never happen in the real
> > world), no ?
> 
> No. Since MIPS{32,64}R2 the CP0 is standardized and a mandatory part of
> a MIPS compatible CPU.

Yes, I know MIPS want always CP0 to be present. I should have put a
smiley somewhere. I wanted just to point the fact that the CPU itself
does not need the CP0 controller to run and that one could easily
imagine designing a core without the CP0 controller. Yes, this would not
follow the specification but it would be able to run....
The biggest conceptual problem would you have to read a CP0 register when you 
want to know what coprocessor are actually implemented !
But all this is a foolish idea....

> > The problem is also: what does this patch adds, but complexity and
> > arbitrary limitations ?
> 
> For MIPS it adds an abstraction layer between the interrupt controller
> and the CP0 registers which will be useful to implement support for
> SMP devices.

Could you please explain me what you can do now that you were not able
too without this patch ?

> 
> > What do you need to route an IRQ ?
> > -> A peripheral destination
> > What we got now ?
> > -> a callback with 3 parameters: an opaque, a PIN (the n_IRQ) and a
> > state
> 
> A pin number doesn't look like a reasonable abstraction for a packetized
> interrupt on an interconnection fabric (like it is used on e.g O2000).
> It may do for the machines we currently emulate, though.

Could you please tell me more about this problem ?
And could you please explain me how the patch solves this, as it just
does not seem to me that it uses more than an IRQ number to identify an
IRQ ?

I though a little bit more about a generic IRQ and/or IO implementation
and it seems that the commited patch is far from solving any pending
problem about it.
What appears to me is that a IO can have 3 "natural state", when not
driven:
- pulled up
- pulled low
- floating
An IO driver can then have 3 actions on an IO line:
- drive it up
- drive it low
- release it
It appears to me that all the possible combinations of thoses natural
states / driving states have to be managed properly to emulate IRQ.
For ISA like IRQ, that are not sharable, IRQ lines are naturally
floating and can be drived up or low
For PCI like IRQs, that are sharable, IRQ lines are naturally pulled up
and can be drived down or released.
Some other designs may use (less often) pulled down sharable IRQ lines.
The first idea is to say that floating IOs can only be driven up or low
and pulled up/low IO can only be driven or not driven. It appears that
because of poorly designed hardware or (more often) software bugs, weird
situations can happen and must be handled: floating IO not driven (which
may gives undefined state on real hardware) or pulled up IO drived up
(same for down, this may give intermediate states between logical 0 and
1 thus product "strange" results).
All those situations can be seen on IRQ line so a generic IRQ
implementation have to manage all those cases.
Now, let's see the other side of the connection. A simplistic approach
would be to say we just need a callback or a stored value. Thinking a
little more about it shows that we cannot do without having at least 2
possible outputs. The reason is that you often have the possibility for
the driving device to read back the value of the IRQ pin and that you
cannot rely on the device internal state for this as an IO may be shared
or may not have the awaited value, especially if not driven properly by
the software.
Even worse, if you are to drive an IRQ with a pure GPIO pin you will
have to set this pin as an bidirectional I/O if you want to be able to
read its actual value back. On some embedded hardware, where I/O pins
cannot be set in a bidirectional mode, you may have to use 2 I/O to
drive and read back an IRQ line state. And it's very useful to be able
to read back hardware states, and quite usual.
My conclusion about it is that it seems that it is mandatory to manage
the 3 possible natural states of an IO, the 3 "driven" state, multiple
sources and multiple outputs if you want to have a correct emulation of
physical IRQ lines behavior. It seems all the work is still to be done
to achieve this.
And doing this would provide a correct emulation for IRQ line and it
seems to me that it will be perfectly usable to emulate any kind of GPIO
line.
But I still cannot agree that the informations about an IO line is to be
stored anywhere else than in the driver device and the receiver one. CPU
and other devices even don't have any "knowledge" of an IO line that is
not connected to them, thus should never have to carry any information
about it.
And I still cannot see why two different structures would be needed to
express one single simple concept of an IO connection.
Please explain me about those points if I'm wrong.

-- 
J. Mayer <address@hidden>
Never organized