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
