From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HaYg6-0004CO-Lj for qemu-devel@nongnu.org; Sun, 08 Apr 2007 10:47:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HaYg5-0004Br-4S for qemu-devel@nongnu.org; Sun, 08 Apr 2007 10:47:38 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HaYg4-0004Bo-Uc for qemu-devel@nongnu.org; Sun, 08 Apr 2007 10:47:37 -0400 Received: from phoenix.bawue.net ([193.7.176.60] helo=mail.bawue.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HaYcL-0007d2-P7 for qemu-devel@nongnu.org; Sun, 08 Apr 2007 10:43:46 -0400 Date: Sun, 8 Apr 2007 15:41:03 +0100 Subject: Re: IRQ handling (was [Qemu-devel] qemu Makefile.target vl.h hw/acpi.c hw/adlib.c ...) Message-ID: <20070408144103.GM21953@networkno.de> References: <200704072145.27203.paul@codesourcery.com> <1175984294.1516.33.camel@rapid> <200704080013.14771.paul@codesourcery.com> <1175990048.1516.77.camel@rapid> <20070408000420.GJ21953@networkno.de> <1176018595.1516.115.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1176018595.1516.115.camel@rapid> From: Thiemo Seufer Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "J. Mayer" Cc: qemu-devel@nongnu.org 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