Date: Wed, 16 Oct 1996 01:13:22 -0700 From: Chris Browning <cbrown@aracnet.com> To: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... Message-ID: <32649922.2A14@aracnet.com> References: <199610150816.CAA07140@clem.systemsix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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. Actually, I am talking about the APIC bus spec. It supports 255 interrupt sources. The P6 (I'm not sure about the P5) atleast supports this. When you say IP APIC, which one are you talking about? I know of atleast 3 that are commonly found on systems, probably more. Each of them has a different number of interrupts and capabilies. Not to mention systems with more than one IO APIC. > >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. Yeah, I think this is correct. > >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! What do you need to know? The machine I am tying this message on right now has 2 IO APICs in it. Neither are PIIX/PIIX3. > 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...) Nice explaination! BTW, if the machine is using VWM, then it is using the APIC bus for part of the interrupt delivery, eventhough it is trasparent to the OS. Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32649922.2A14>