From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MaUhm-0004Uj-6R for qemu-devel@nongnu.org; Mon, 10 Aug 2009 09:14:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MaUhg-0004U1-Gj for qemu-devel@nongnu.org; Mon, 10 Aug 2009 09:14:24 -0400 Received: from [199.232.76.173] (port=49562 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MaUhg-0004Ty-E2 for qemu-devel@nongnu.org; Mon, 10 Aug 2009 09:14:20 -0400 Received: from mail.gmx.net ([213.165.64.20]:60972) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MaUhf-0008QU-Jb for qemu-devel@nongnu.org; Mon, 10 Aug 2009 09:14:20 -0400 Date: Mon, 10 Aug 2009 15:14:41 +0200 From: Olaf Dabrunz Subject: Re: [Qemu-devel] [PATCH 1/2] Route PC irqs to ISA bus instead of i8259 directly Message-ID: <20090810131441.GB14714@santana.dyndns.org> References: <1249836296-13288-1-git-send-email-avi@redhat.com> <1249836296-13288-2-git-send-email-avi@redhat.com> <2202BB40-5CA5-462B-8A5A-A9657B370B6D@suse.de> <4A7FEC23.1050708@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7FEC23.1050708@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Assmann Cc: "qemu-devel@nongnu.org" , Olaf Dabrunz , Alexander Graf , Avi Kivity On 10-Aug-09, Stefan Assmann wrote: > On 10.08.2009 11:04, Alexander Graf wrote: >> >> Am 09.08.2009 um 18:44 schrieb Avi Kivity : >> >>> A PC has its motherboard IRQ lines connected to both the PIC and IOAPIC. >>> Currently, qemu routes IRQs to the PIC which then calls the IOAPIC, an >>> incestuous arrangement. In order to clean this up, create a new ISA IRQ >>> abstraction, and have devices raise ISA IRQs (which in turn raise the >>> i8259 >>> IRQs as usual). >> >> Is this really true? From my understanding the PIC in modern systems is >> emulated through the IOAPIC, which is the reason we have legacy interrupts. > > While not sure how the hardware implementation is done in detail I can > confirm that the IRQs indeed end up at both PIC and IO-APIC0 if the > device is connected to the southbridge directly. If that's not the case > for example a PCI bus connected via PCIe that sports it's own IO-APIC > then IRQs are forwarded (over PCIe) from the IO-APIC to the southbridge > (PIC). To be exact, IRQs on modern PCs are routed to both an IO-APIC and the PIC via wires and some routing mechanism. (Support for the PIC is required by ACPI.) The routing mechanism to the PIC does _not_ involve an IO-APIC. It is implementation-specific to the chipset and the board, and operating systems get routing info from the ACPI tables (delivered by the BIOS). The routing to the PIC is set up by the BIOS, which knows how to program the chipset-specific routing registers. The IO-APICs are standard components that are programmed by the operating system. They do not have any "forwarding to the PIC" component. The intention is that there are no implementation-specific differences between them (except for number of lines, the generation of the IO-APIC spec and slight differences in the hardware implementation). They are supposed to be programmable by the OS in a standard way. That is why they cannot be part of a scheme that routes IRQs to the PIC. Now that being said, there are mechanisms like boot interrupts that on some chipsets activate forwarding of interrupts to the PIC, when the corresponding "line" in a (secondary) IO-APIC is disabled. This means that the IO-APIC state is "sampled" by some logic to select forwarding to the PIC. The IO-APIC itself is not part of this mechanism, it is just "being watched". > In any case, to come closer to the real hardware having an abstraction > that receives IRQs from devices and delivers them to the appropriate > interrupt controller(s) seems to be a valid step IMHO. > > Does qemu support multiple IO-APICs? I guess not so no need for boot > interrupts. (If yes then there would be the question how close you > really want to be to existing hardware.) > > Stefan -- Olaf Dabrunz (Olaf.Dabrunz gmx.net)