Re: [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...

[Paul Brook]

On Saturday 07 April 2007 23:18, J. Mayer wrote:
> It seems that you don't figure out how real hardware works AT ALL.
> IRQ callbacks and private data CANNOT BE SHARED as they are INTERNAL TO
> ONE IRQ CONTROLLER. IRQ management, once again, is completelly specific
> to an IRQ controller technology and absolutely not related to the CPU
> you may use on the same board. So it's a complete nonsense to try to
> share IRQ notion in the CPU. IRQ notions and management is completely
> different to one IRQ controller technology to another.
<snip>

You appear to have misunderstood what my patch does. The arguments you use in 
the part of the email I snipped are the same resons why I created this patch.


The most important thing to understand is that the "qemu_irq" object is simply 
an abstract interface for connecting two devices. One of which produces a 
single-bit output, and the other does something in response to that signal. 
qemu_irq isn't an ideal name because it's used for things other than physical 
IRQ pins. However it's the best we (Me, Theimo, or anyone else on #qemu about 
24 hours ago) could come up with.

The purpose of this abstraction is precisely so that interrupt sources and 
sinks can be chained and rearranged in arbitrary fashion.


In the specific case of PPC a typical system, as you say, has several cascaded 
levels of interrupt handling. You have multiple external interrupt 
controllers, including interrupts from PCI bus based devices. 

Contrary to your assertion, a PPC cpu does contains an internal vectored 
interrupt controller. This handles the external IRQ pin, plus various 
internal interrupt sources (as defined by the PPC_INTERRUPT_* constants). 
This is what the IRQ array in the cpu state structure is for. I see no 
fundamental reason why this should be treated any differently to an external 
interrupt controller.

Because these are currently implemented in the same file I didn't bother 
converting them fully and they mostly still use ppc_set_irq dircetly instead 
of going via qemu_set_irq. If/when ppc.c is split up and/or cpus with more 
than one external IRQ pin are added the generic IRQ routing mechanisms allow 
this to happen without having to export ppc_set_irq.

PPC is a slightly bad example because it still has ppc_openpic_irq. This is 
exactly the sort of horrible system specific hack I'm trying to replace.


Before my patch chained interrupts were handled with a messy ad-hoc 
combination of callbacks and opaque parameters. Some devices were properly 
parameterized, others assumed that their IRQ output went to a specific device 
or CPU.

My patch introduces a generic mechanism for devices to talk to an interrupt 
controller. It means that the code signalling the interrupt doesn't need to 
know or care where it ends up. The logic for implementing a particular 
interrupt controller is still private to that device.

I have not created a single flat IRQ super-controller, just a consistent 
mechanism for glueing the existing bits of emulation together.

> You broke the commited code.... And you also completely break any new
> development for the PowerPC target as most real machine cannot be
> emulated now (even PREP is broken, using 3 IRQ controllers).

Can you send me a testcase of something that worked before my patch and 
doesn't afterwards? As I said above, handling of multiple IRQ controllers is 
significantly better after my patch than it was before.

Paul