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

[J. Mayer]

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.

On Sat, 2007-04-07 at 21:45 +0100, Paul Brook wrote:
> On Saturday 07 April 2007 21:28, J. Mayer wrote:
> > On Sat, 2007-04-07 at 20:10 +0100, Paul Brook wrote:
> > > On Saturday 07 April 2007 19:32, J. Mayer wrote:
> > > > On Sat, 2007-04-07 at 18:14 +0000, Paul Brook wrote:
> > > > > CVSROOT:      /sources/qemu
> > > > > Module name:  qemu
> > > > > Changes by:   Paul Brook <pbrook>     07/04/07 18:14:41
> > > >
> > > > The patches in the PowerPC target seem complete nonsense.
> > >
> > > Can you give specific examples?
> >
> > I'm talking about the CPU code.
> > There is NO notion of external IRQ allocation in the PowerPC
> > specification.
> 
> Quoting from ppc.c (both before and after my patch):
> 
> /*****************************************************************************/
> /* PowerPC internal fake IRQ controller
>  * used to manage multiple sources hardware events
> 
> My patch did not change how this worked at all. It just changed it from using 
> an ad-hoc system of callpacks and opaque parameters to using a standard 
> mechanism for connecting interrupt sources, be they internal or external.
> 
> MIPS works exactly the same way.

No. MIPS CPU have an internal IRQ controller and often one or many
external ones. It's completely different and cannot be easily compared
to what done internally in a PowerPC.

> > Where do you see that a
> > machine with a PowerPC cannot manage more than 32 IRQ ?
> 
> Any PPC that needs more that 32 internal interrupt sources is already broken. 
> Notice how the old bitmask is a uint32_t.

You don't understand a single word of what I wrote or you don't
understand at all what is the difference between a CPU and an IRQ
controller.
The code you quote concerns INTERNAL EXCEPTION MANAGEMENT. It's no way
related with an IRQ controller and will never be. One or more exception,
like in any CPU, can be connected to an IRQ controller (or more,
cascaded, for example). The IRQ management is done inside the IRQ
controller, not in the CPU and all the hardware IRQ interface are
SPECIFIC to the IRQ controller. Then, this is to be emulated internally
in the controller and has no notion to be shared in the CPU (as there is
none in the real hardware).
The existing code ACTUALLY WORKS with more than 32 IRQs as you can
cascade any number of IRQ controller one to the other. Each IRQ
controller handle its own events and manage the callbacks to the
cascade. There is only one controller in the chain connected to the CPU.
Then, you can virually have an infinite number of IRQ, managed by a
chain of controllers, using different technologies then cannot share any
data execpt the IRQ events on the cascade. THAT's HOW REAL HARDWARE
WORKS AND THAT'S HOW IT'S EMULATED FOR POWERPC IN THE CODE BEFORE YOU
BREAK IT !

> > SO your patch is a complete nonsense and YES IT BREAKS MY WORKS SO IT
> > HAS TO BE REVERTED.
> 
> I can only fix the code that I have access to.

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).

> However if there is agreement from other maintainers I will revert my patch.

I only ask you to revert all that affects the PowerPC target. If the
other developpers want their target to follow this broken way, it does
not hurt me as long as it does not break fundamental concept for PowerPC
emulation.

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