Date: Tue, 15 Oct 1996 02:16:28 -0600 From: Steve Passe <smp@csn.net> To: Peter Wemm <peter@spinner.dialix.com> Cc: cbrown@aracnet.com, smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... Message-ID: <199610150816.CAA07140@clem.systemsix.com> In-Reply-To: Your message of "Tue, 15 Oct 1996 14:27:12 %2B0800." <199610150627.OAA18081@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, >Chris Browning wrote: >> Steve Passe wrote: >> ... >> Ah hem, the limit on the APIC bus, according to page 7-11 of the Pentium >> (TM) Pro >> Family Developers Manual, Volume 3 is 255. I believe this is standard >> ... > >We were talking about the software side of it. :-) The limit used to be >16 hardware interrupts, we can now deal with 24, although we could >probably squeeze a few more in. The software "interrupts" take a few >slots too. Even more specifically, we are talking about the INPUT capabilities of the IO APIC, a discrete component, NOT the "local APICs" found on P5/P6 CPUs. --- >Is the 8259-workalike in the piix3 in the 430HX chipset or in the other >"big" chip? It appears that it is in the piix3. looking this up I found another missing piece of the puzzle: section 2.2.10 of the piix3 manual. This documents the PI/ISA INT redirection registers. It states: "When a PIRQ signal is routed to an interrupt controller IRQ the PIIX/PIIX3 masks the corresponding IRQ signal." So setting the "disable" bit in one of these registers should free the corresponding ISA INT for use by other hardware (ie 'disable' should both unamsk the ISA bus IRQ and and undirect the PCI PIRQ.) --- >> sharing interrupts. Of course, all the drivers will have to be >> rewritten if they can't >> handle shared interrupts. > >>I believe the existing PCI irq code already handles this. It's just a >matter of making sure that it still works with the APIC's active. I have >not looked at Steve's changes to the pci code yet. At on time I thought I saw something in the generic (non-PCI) side of the INT code (vector.s perhaps?) that was a minor problem for sharing but I can't remember what it was right now... --- >Only one IO apic is supported at present, but I think we know about one >motherboard that has two IO apic's already (and two pci busses, etc), so >we've got to deal with having 48 or so hardware IRQ's on currently >existing hardware. The present irq masking architecture depends on being >able to locate the originating IO apic quickly to mask further interrupts >during the handler, so having both IO apics generating overlapping IDT >vectors is "too hard" at present. I'm sure Steve will yell if I've >misunderstood his code. Here I define 'too hard" more as "unknown". Not enough info is available to me right now to do support for multiple IO APICs. Once I see how a "2 IO APIC" machine "looks" it might not turn out to be a big problem. In general, Peter has explained what I've been doing better than I could! For those of you not privy to the details of this IO APIC work, what I have done so far has been the "conversion" of the existing kernel code that uses the 8259 ICUs to code that uses the "InputOutput AdvancedProgrammableIntController" By itself, this has no real benefit to the kernel, exactly the same things is being accomplished, but with a different body of code and a different piece of silicon. It's the next step that all this is being done for. That step is where we start using the advanced features provided by the general distributed APIC mechanism. The first thing to know is that in addition to the motherboad's IO APIC(s) each CPU has an APIC. All the APICs are tied together on their own private bus. The IO APIC can be programmed to deliver each INT vector to a specific CPU, or to a subset of CPUs, or to all CPUs. Beyond this there are several ways of creating "arbitration" algorithms where the CPUs actually decide between themselves which will accept an INT based on the "priority level" it is currently running at. CPUs can also send "system InterProcessorInterrupts". these are effectively software interrupts sent over the APIC bus from one CPU to another. Among other things, we will use these capabilities to steer INTs to the CPU most suited for handing the INT (several reasons why this is necessary, but thats another discussion...) -- Steve Passe | powered by smp@csn.net | FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610150816.CAA07140>