Is it possible (on x86) to remap an IRQ - say the keyboard IRQ 1 - only with APIC programming to another interrupt vector?
As i understand the docs i can map the LINT0 and LINT1 IRQs to a given (constant) vector or i can tell the APIC to use the external vector (from a 8259). But mapping ie IRQ 1 to vector 47 and IRQ 3 to vector 55 is not possible with APIC programming only. Am i right?
Remapping IRQ with APIC without 8259 on x86?
-
Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
The Local APIC does not generate the interrupt numbers for IRQs, the PICs do. You can not make the PIC map each IRQ to a specific vector, they always come in groups of eight.
The I/O Apic might provide the functionality you want, but i don't know the details of it, and its not present in all machines.
The I/O Apic might provide the functionality you want, but i don't know the details of it, and its not present in all machines.
Yeah. You're looking for the IO APIC. In my kernel, I'm disabling the legacy PIC and remapping the IOAPIC IRQs accordingly. It's actually quite simple to use too... it's all memory mapped.
http://www.google.com/codesearch?hl=en& ... oapic.c#a0
I wrote this code. It checks to see if an IO APIC is present. If it is, it disables the legacy PIC and remaps the IRQs. Best to read the Intel docs, though...
http://www.google.com/codesearch?hl=en& ... oapic.c#a0
I wrote this code. It checks to see if an IO APIC is present. If it is, it disables the legacy PIC and remaps the IRQs. Best to read the Intel docs, though...
Hi,
The only way to use the I/O APICs correctly (unless you write code for a specific motherboard) is to parse tables provided by the BIOS. There's 2 different specifications - Intel's Multiprocessor Specification (which is an older specification originally intended for SMP that is much simpler) and the ACPI specification (which is an overcomplicated mess designed for everything, but is very similar to Intel's Multiprocessor specification if you ignore everything you don't need).
In general, there's no need for the same devices to be connected to the same inputs on both the PICs and the I/O APICs. For example, often the PIT timer is connected to "input 0" on the master PIC and connected to "input 2" on the I/O APIC.
Each I/O APIC input must be programmed correctly, depending on the type of signal the hardware connected to it uses. Signals from the ISA bus are normally "edge triggered active high", but signals from a PCI bus are normally "level triggered active low" and signals from the motherboard (SMI, ExtINT, NMI, etc) could be anything.
For some systems there are more than one I/O APIC, and I/O APICs may not have 24 inputs. For example, the computer I'm typing this on has a pair of I/O APICs that have 16 inputs each. Also the physical addresses of I/O APICs usually start at 0xFEC00000, but this isn't always the case and there's no reason for BIOS/motherboard manufacturers to do this (it's common practice but not required).
Lastly, for PCI devices the BIOS stores the "IRQ number" that a device uses in the device's PCI configuration space so that the OS can figure out which IRQ the device generates. These are PIC interrupt numbers and are useless once the OS starts using the I/O APIC (usually PCI interrupts are not connected to the first 16 I/O APIC inputs to reduce IRQ sharing). Without parsing BIOS tables you won't know which PCI devices are connected to which I/O APIC inputs.
Cheers,
Brendan
Please understand that the code posted by Durand is only rough example code (I'm guessing he uses it for Bochs or Qemu only), and his comment about reading the Intel documentation should be strongly considered.Steffel wrote:Thanks a lot. Exactely what i looked for.
The only way to use the I/O APICs correctly (unless you write code for a specific motherboard) is to parse tables provided by the BIOS. There's 2 different specifications - Intel's Multiprocessor Specification (which is an older specification originally intended for SMP that is much simpler) and the ACPI specification (which is an overcomplicated mess designed for everything, but is very similar to Intel's Multiprocessor specification if you ignore everything you don't need).
In general, there's no need for the same devices to be connected to the same inputs on both the PICs and the I/O APICs. For example, often the PIT timer is connected to "input 0" on the master PIC and connected to "input 2" on the I/O APIC.
Each I/O APIC input must be programmed correctly, depending on the type of signal the hardware connected to it uses. Signals from the ISA bus are normally "edge triggered active high", but signals from a PCI bus are normally "level triggered active low" and signals from the motherboard (SMI, ExtINT, NMI, etc) could be anything.
For some systems there are more than one I/O APIC, and I/O APICs may not have 24 inputs. For example, the computer I'm typing this on has a pair of I/O APICs that have 16 inputs each. Also the physical addresses of I/O APICs usually start at 0xFEC00000, but this isn't always the case and there's no reason for BIOS/motherboard manufacturers to do this (it's common practice but not required).
Lastly, for PCI devices the BIOS stores the "IRQ number" that a device uses in the device's PCI configuration space so that the OS can figure out which IRQ the device generates. These are PIC interrupt numbers and are useless once the OS starts using the I/O APIC (usually PCI interrupts are not connected to the first 16 I/O APIC inputs to reduce IRQ sharing). Without parsing BIOS tables you won't know which PCI devices are connected to which I/O APIC inputs.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.