Date: Tue, 15 Oct 1996 14:27:12 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: cbrown@aracnet.com Cc: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... Message-ID: <199610150627.OAA18081@spinner.DIALix.COM> In-Reply-To: Your message of "Mon, 14 Oct 1996 21:19:38 MST." <326310DA.2A9B@aracnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Browning wrote:
> Steve Passe wrote:
> > > Once the system is
> > > running fully symmetric, you have a total of 20 interrupts available. Th
e
> >
> > theoretical limit is 24, on mine I have 21:
>
> 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
> for all
> system implementing the APIC bus. Now, your motherboard may limit you
> to less, but not
> the APIC bus.
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.
We've been talking offline about an alternate strategy which should allow
us to do masking for all 224 possible IDT entries, not just the 16 (or 24)
that correspond to hardware origin.
> > 1 cascade of MASTER 8259 INTR out (not used in symmetric mode).
> > 15 ISA. (8259 SLAVE out has no meaning)
> > 4 PCI.
> > 1 SMI (System Management INT)
> >
> > > IDE interrupts will disappear from irq-14 and 15 once it's switched to
> > > symmetric mode, so if you have smart cards in there that have programmabl
e
> > > irq's, those will be available for assignment shortly after boot. Once
>
> Hmm, I'm not sure if this is true by default. Unless the OS goes in and
> moves those
> devices, they will stay where they are.
According to the mpspec, there is a pci->isa mapping system that is
supposed to "sense" when the system switches into symmetric mode and
disable itself when the io apics are activated. So, it depends on how the
ide irq's originate I guess. If they originate as "pci interrupts" that
go through the redirection matrix, then in theory the isa irq14/15 signals
should be freed up. However, Intel could well have hardwired it so that
the piix3 chipset generates isa edge triggered interrupts only and cannot
do pci-style level sensative irq's.
Is the 8259-workalike in the piix3 in the 430HX chipset or in the other
"big" chip? If the ide and 8259's are on the same chunk of silicon, they
may be hardwired on the chip with the on-chip IDE only being "on" or "off"
on the hardwired configuration.
Specifically, it says that if the motherboard doesn't support PIC mode and
the IMCR, there cannot be any other steps to disable the remapping.. It
has to be automatic when the apics are programmed. If the IMCR is
present, it can use that to turn the pci irq map registers on and off.
> > But what does change is that you have the additional IO APIC INTS 16 thru
> > 23, 4 of which will be available for your PCI cards. Which means they won't
> > have to compete with ISA cards for the 1st 16 INTS.
>
> Wrong. According to the same page I quoted above, interrupts 16-31 are
> reserved for processor
> use. This may be different on a non PPro system. 32-255 are available
> for general purpose use.
> Now, from an OS prespective, you may never see 16-31 and the rest may
> get shifted down, since this
> is all done in HW.
You are confusing the isa hardware interrupts with the processor's IDT
(interrupt descriptor table). Currently, the 16 isa interrupts are mapped
into IDT entries 32 through 47. With the work Steve's been doing, the IO
Apic's have vector numbers 32 through 55 programmed into them. So, when
the 8259 pics are disabled, the IO APIC produces the exact same interrupt
vectors, just more of them.
Currently the IRQ's are directly mapped in a 1:1 ratio to the IDT table,
but there's no need to. If there's a space squeeze to fit all the devices
into a 32 bit mask, for example, there's nothing stopping us compacting it.
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.
> You will have to compete for the ISA interrupts still, unless you have a
> lot of PCI devices
> you don't want to be visible at boot time (i.e. moving your super-fancy
> SCSI card to an
> interrupt above 15 will mean you can't see it until you get into the OS)
No, this is not an issue.. The BIOS boots in "virtual wire" mode, with
the PCI->ISA mapping active. So, an arbitrary PCI interrupt may already
be hardwired to the IO APIC on int18, and _also_ be switched through to
the inputs of the 8259-clone PICs. The APIC only sees the given pci IRQ
line on interrupt 18, and never sees the result of the pci->isa mapping to
the 8259 pics.
> > And they are direct, active low, level triggered INTs (if so programmed),
> > so they should be sharable (although sharing will require additional
> > code changes).
>
> Hmm, it would be good to add this. Things get pretty limited these days
> without
> 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.
The "problem" is that we have to make sure that we can handle any "curve
ball"'s that may be in the various motherboard's mpconfig tables. If the
mp table says that pci device 6 is on apic channel #18, we don't have a
choice, the motherboard is wired that way and the pci->isa irq mapping
refisters are no longer present. If it says that the piix3 is hardwired
to 'edge trigger' mode on irq14 even after switching to symmetric mode, we
simply have to deal with it.
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610150627.OAA18081>