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