Advanced Programmable Interrupt Controller Driver Linux

Interrupt Controller¶ This board uses the kernel’s static Interrupt Descriptor Table (IDT) to program the Advanced Programmable Interrupt Controller (APIC) interrupt redirection table. This is a collection of lectures and labs Linux kernel topics. The lectures focus on theoretical and Linux kernel exploration. The labs focus on device drivers topics and they resemble “howto” style documentation. The UNIX and Linux Forums. Today's Posts. Apic --Advanced Programmable Interrupt Controller (APIC) driver. Each local APIC includes one 32-bit programmable timer. This driver uses them to supply kernel with one event timer named 'LAPIC'. Event timer provided by the driver supports both one-shot.

Advanced Programmable Interrupt Controller
Advanced Programmable Interrupt Controller Driver Linux Download
8259 Programmable Interrupt Controller
Programmable Interrupt Controller Driver

In computing, Intel's Advanced Programmable Interrupt Controller (APIC) is a family of interrupt controllers. As its name suggests, the APIC is more advanced than Intel's 8259Programmable Interrupt Controller (PIC), particularly enabling the construction of multiprocessor systems. It is one of several architectural designs intended to solve interrupt routing efficiency issues in multiprocessor computer systems.

The APIC is a split architecture design, with a local component (LAPIC) usually integrated into the processor itself, and an optional I/O APIC on a system bus. The first APIC was the 82489DX – it was a discrete chip that functioned both as local and I/O APIC. The 82489DX enabled construction of symmetric multiprocessor (SMP) systems with the Intel 486 and early Pentium processors; for example, the reference two-way 486 SMP system used three 82489DX chips, two as local APICs and one as I/O APIC. Starting with the P54C processor, the local APIC functionality was integrated into the Intel processors' silicon. The first dedicated I/O APIC was the Intel 82093AA, which was intended for PIIX3-based systems.

3Integrated local APICs

Overview[edit]

There are two components in the Intel APIC system, the local APIC (LAPIC) and the I/O APIC. There is one LAPIC in each CPU in the system. In the very first implementation (82489DX), the LAPIC was a discrete circuit opposed to its thereafter implementation in Intel processors' silicon. There is typically one I/O APIC for each peripheral bus in the system. In original system designs, LAPICs and I/O APICs were connected by a dedicated APIC bus. Newer systems use the system bus for communication between all APIC components.

Each APIC, whether a discrete chip or integrated in a CPU, has a version register containing a four-bit version number for its specific APIC implementation. For example, the 82489DX has an APIC version number of 0, while version 1 was assigned to the first generation of local APICs integrated in the Pentium 90 and 100 processors.^[1]

In systems containing an 8259 PIC, the 8259 may be connected to the LAPIC in the system's bootstrap processor (BSP), or to one of the system's I/O APICs, or both. Logically, however, the 8259 is only connected once at any given time.

Discrete APIC[edit]

The first-generation Intel APIC chip, the 82489DX, which was meant to be used with Intel 80486 and early Pentium processors, is actually an external local and I/O APIC in one circuit. The Intel MP 1.4 specification refers to it as 'discrete APIC' in contrast with the 'integrated APIC' found in most of the Pentium processors.^[2] The 82489DX had 16 interrupt lines;^[3] it also had a quirk that it could lose some ISA interrupts.^[4]

In a multiprocessor 486 system, each CPU had to be paired with its own 82489DX; additionally a supplementary 82489DX had to be used as I/O APIC. The 82489DX could not emulate the 8259A (XT-PIC) so these also had to be included as physical chips for backwards compatibility.^[5] The 82489DX was a packaged as a 132-pin PQFP.^[3]

Integrated local APICs[edit]

Local APICs (LAPICs) manage all external interrupts for some specific processor in an SMP system. In addition, they are able to accept and generate inter-processor interrupts (IPIs) between LAPICs. LAPICs may support up to 224 usable interrupt vectors from an I/O APIC. Vector numbers 0 to 31, out of 0 to 255, are reserved for exception handling by x86 processors.

All Intel processors starting with the P5 microarchitecture (P54C) have a built-in local APIC.^[6]^[7] However, if the local APIC is disabled in a P5 processor, it cannot be re-enabled by software; this limitation no longer exists in the P6 processors and later ones.^[7] In single-processor systems, the major advantage of the local APIC is that PCI cards no longer need to have their interrupts mapped to ISA interrupts, but can use virtual PCI IRQs above 15, resulting in fewer conflicts and better performance.^[6]

In the Microsoft family of operating systems, Windows XP was the first to properly make use of virtual IRQs provided by the local APIC, with some partial support present in Windows 2000.^[6] In Windows 2000, the spreading of PCI card interrupts to virtual IRQ happens only if the machine also has an I/O APIC. Microsoft blamed their Windows 2000 implementation on information they had received from Intel supposedly promising that all future systems would contain an I/O APIC as well, something that in retrospect did not happen.^[8] (A Microsoft document from that era even claimed that 'without an I/O APIC in the system, the local APICs are useless. In such a situation, Windows 2000 has to revert to using the 8259 PIC.'^[9]) The sudden widespread use of the local APIC with Windows XP did expose a number of bugs in various BIOS implementations. In particular, Microsoft was forced to retain the PCI IRQ stacking behavior for any machine with a CardBus controller (and without an I/O APIC).^[8]

The Message Signaled Interrupts (MSI) feature of the PCI 2.2 and later specifications cannot be used without the local APIC being enabled.^[8] Use of MSI obviates the need for an I/O APIC. Additionally, up to 224 interrupts are supported in MSI mode, and IRQ sharing is not allowed.^[10]

APIC timer[edit]

Another advantage of the local APIC is that it also provides a high-resolution (on the order of one microsecond or better) timer that can be used in both interval and one-off mode.^[7]

The APIC timer had its initial acceptance woes. A Microsoft document from 2002 (which advocated for the adoption of High Precision Event Timer instead) criticized the LAPIC timer for having 'poor resolution' and stating that 'the clocks silicon is sometimes very buggy'.^[11] Nevertheless, the APIC timer is used for example by Windows 7 when profiling is enabled, and by Windows 8 in all circumstances. (Before Windows 8 claimed exclusive rights to this timer, it was also used by some programs like CPU-Z.) Under Microsoft Windows the APIC timer is not a shareable resource.^[12]

The aperiodic interrupts offered by the APIC timer are used by the Linux kernel from 2.6.18 onwards to implement its tickless kernel feature; the legacy 8253Programmable Interval Timer is no longer used by tickless kernels.^[13] A VMware document notes that 'software does not have a reliable way to determine its frequency. Generally, the only way to determine the local APIC timer’s frequency is to measure it using the PIT or CMOS timer, which yields only an approximate result.'^[14]

I/O APICs[edit]

I/O APICs contain a redirection table, which is used to route the interrupts it receives from peripheral buses to one or more local APICs. The first-generation dedicated I/O APIC, the 82093AA, had support for 24 interrupt lines.^[10] It was packaged as a 64-Pin PQFP.^[15] The 82093AA normally connected to the PIIX3 and used its integrated legacy 8259 PICs.^[15]

According to a 2009 Intel benchmark using Linux, the I/O APIC reduced interrupt latency by a factor of almost three relative to the 8259 emulation (XT-PIC), while using MSI reduced the latency even more, by a factor of nearly seven relative to the XT-PIC baseline.^[16]

Variants[edit]

The xAPIC was introduced with the Pentium 4, while the x2APIC is the most recent generation of the Intel's programmable interrupt controller, introduced with the Nehalem microarchitecture in November 2008.^[17] The major improvements of the x2APIC address the number of supported CPUs and performance of the interface.

The x2APIC now uses 32 bits to address CPUs, allowing to address up to 2³² − 1 CPUs using the physical destination mode. The logical destination mode now works differently and introduces clusters; using this mode, one can address up to 2²⁰ − 16 processors. The x2APIC architecture also provides backward compatibility modes to the original Intel APIC Architecture (introduced with the Pentium/P6) and with the xAPIC architecture (introduced with the Pentium 4).

The improved interface reduces the number of needed APIC register access for sending Inter-processor interrupts (IPIs). Because of this advantage, QEMU can and does emulate x2APIC for older processors that do not physically support it, going back to Conroe and even for AMD Opteron G-series processors (neither of which natively support x2APIC).^[18]^[19]

APICv is the Intel's brand name for hardware virtualization support aimed at reducing interrupt overhead in guests. APICv was introduced in the Ivy Bridge-EP processor series, which is sold as Xeon E5-26xx v2 (launched in late 2013) and as Xeon E5-46xx v2 (launched in early 2014).^[20]^[21]^[22] AMD announced a similar technology called AVIC,^[23]^[24] it is available family 15h models 6Xh (Carrizo) processors and newer.^[25]

Issues[edit]

There are a number of known bugs in implementations of APIC systems, especially with concern to how the 8254 is connected. Defective BIOSes may not set up interrupt routing properly, or provide incorrect ACPI tables and Intel MultiProcessor Specification (MPS) tables.

The APIC can also be a cause of system failure when the operating system does not support it properly. On older operating systems, the I/O and local APICs often had to be disabled. While this is not possible anymore due to the prevalence of symmetric multiprocessor and multi-core systems, the bugs in the firmware and the operating systems are now a rare occurrence.

Competition[edit]

AMD and Cyrix once proposed a somewhat similar-in-purpose OpenPIC architecture supporting up to 32 processors;^[26] it had at least declarative support from IBM and Compaq around 1995.^[27] No x86 motherboard was released with OpenPIC however.^[28] After the OpenPIC's failure in the x86 market, AMD licensed Intel's APIC for its AMD Athlon and later processors.

IBM however developed their MultiProcessor Interrupt Controller (MPIC) based on the OpenPIC register specifications.^[29] MPIC was used in PowerPC based designs, including those of IBM, for instance in some RS/6000 systems,^[30] but also by Apple, as late as their Power Mac G5s.^[31]^[32]

References[edit]

^Intel MultiProcessor Specification, version 1.4, page 3-5, May 1997
^Intel MultiProcessor Specification, version 1.4, page 1-4, May 1997
^ ^a^bBadri Ram (2001). Adv Microprocessors Interfacing. Tata McGraw-Hill Education. p. 314. ISBN978-0-07-043448-6.
^http://people.freebsd.org/~fsmp/SMP/papers/apicsubsystem.txt
^Intel MultiProcessor Specification, version 1.4, page 5-3, May 1997
^ ^a^b^cScott M. Mueller (2011). Upgrading and Repairing PCs (20th ed.). Que Publishing. p. 242. ISBN978-0-13-268218-3.
^ ^a^b^cUwe Walter, Vincent Oberle μ-second precision timer support for the Linux kernel
^ ^a^b^c'Windows Hardware Dev Center'. msdn.microsoft.com.
^'Content not found'. www.microsoft.com.
^ ^a^bJames Coleman, Reducing Interrupt Latency Through the Use of Message Signaled Interrupts, pp. 10-11
^Guidelines For Providing Multimedia Timer Support, September 20, 2002
^Windows 8 and APIC timerArchived February 22, 2014, at the Wayback Machine
^'VMware Knowledge Base'. kb.vmware.com.
^Timekeeping in VMware Virtual Machines (for VMware vSphere 5.0, Workstation 8.0, Fusion 4.0), page 8
^ ^a^b'Resource & Design Center for Development with Intel'. Intel.
^James Coleman, Reducing Interrupt Latency Through the Use of Message Signaled Interrupts, p. 19
^'Intel Nehalem mit X2APIC - Extended xAPIC Architecture (Bild 27/27) - ComputerBase'. www.computerbase.de.
^'Re: [Qemu-devel] [Question] why x2apic's set by default without host sup'. lists.gnu.org.
^'[Qemu-devel] [PATCH] target-i386: enable x2apic by default on more recen'. lists.nongnu.org.
^http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/09/2012-lpc-virt-intel-vt-feat-nakajima.pdf
^'APIC Virtualization Performance Testing and Iozone* - Intel® Software'. software.intel.com.
^http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/xeon-e5-4600-v2-brief.pdf
^Wei Huang, Introduction of AMD Advanced Virtual Interrupt Controller, XenSummit 2012
^http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/09/2012-lpc-virt-interrupt-virt-kvm-roedel.pdf
^'[Xen-devel] [RFC PATCH 0/9] Introduce AMD SVM AVIC'. www.mail-archive.com.
^'OpenPIC Definition from PC Magazine Encyclopedia'. Pcmag.com. 1994-12-01. Retrieved 2011-11-03.
^Brooke Crothers (20 March 1995). AMD, Cyrix offer up alternative SMP spec. InfoWorld. p. 8. ISSN0199-6649.
^André D. Balsa, Note attached to 'Linux Benchmarking: Part III -- Interpreting Benchmark Results' appearing in Issue 24 of Linux Gazette, January 1998
^IBM Multiprocessor Interrupt Controller. Data BookArchived 2014-02-23 at the Wayback Machine
^Arca Systems TTAP Evaluation Facility The IBM Corporation RS/6000 Distributed System Running AIX Version 4.3.1. TCSEC Evaluated C2 Security, p. 29
^Singh, Amit (13 October 2006). Take a Look Inside the G5-Based Dual-Processor Power Mac – via informIT database.
^Power Mac G5 Developer Note (Legacy), p. 26

External links[edit]

Intel 64 Architecture x2APIC Specification (PDF)
More information on the Intel x2APIC Architecture can be found in the Intel 64 and IA-32 Architectures Software Developer's Manuals

Retrieved from 'https://en.wikipedia.org/w/index.php?title=Advanced_Programmable_Interrupt_Controller&oldid=888670321'

Operating systems
Common features

interrupt sources and processor handling

In system programming, an interrupt is a signal to the processor emitted by hardware or software indicating an event that needs immediate attention. An interrupt alerts the processor to a high-priority condition requiring the interruption of the current code the processor is executing. The processor responds by suspending its current activities, saving its state, and executing a function called an interrupt handler (or an interrupt service routine, ISR) to deal with the event. This interruption is temporary, and, after the interrupt handler finishes, the processor resumes normal activities.^[1] There are two types of interrupts: hardware interrupts and software interrupts (softirqs).

Hardware interrupts are used by devices to communicate that they require attention from the operating system.^[2] Internally, hardware interrupts are implemented using electronic alerting signals that are sent to the processor from an external device, which is either a part of the computer itself, such as a disk controller, or an external peripheral. For example, pressing a key on the keyboard or moving the mouse triggers hardware interrupts that cause the processor to read the keystroke or mouse position. Unlike the software type (described below), hardware interrupts are asynchronous and can occur in the middle of instruction execution, requiring additional care in programming. The act of initiating a hardware interrupt is referred to as an interrupt request (IRQ).

A software interrupt is caused either by an exceptional condition in the processor itself, or a special instruction in the instruction set which causes an interrupt when it is executed. The former is often called a trap or exception and is used for errors or events occurring during program execution that are exceptional enough that they cannot be handled within the program itself. For example, a divide-by-zero exception will be thrown if the processor's arithmetic logic unit is commanded to divide a number by zero as this instruction is an error and impossible. The operating system will catch this exception, and can decide what to do about it: usually aborting the process and displaying an error message. Software interrupt instructions can function similarly to subroutine calls and are used for a variety of purposes, such as to request services from device drivers, like interrupts sent to and from a disk controller to request reading or writing of data to and from the disk.

Each interrupt has its own interrupt handler. The number of hardware interrupts is limited by the number of interrupt request (IRQ) lines to the processor, but there may be hundreds of different software interrupts. Interrupts are a commonly used technique for computer multitasking, especially in real-time computing. Such a system is said to be interrupt-driven.^[3]

Interrupts are similar to signals, the difference being that signals are used for inter-process communication (IPC), mediated by the kernel (possibly via system calls) and handled by processes, while interrupts are mediated by the processor and handled by the kernel. The kernel may pass an interrupt as a signal to the process that caused it (typical examples are SIGSEGV, SIGBUS, SIGILL and SIGFPE).

3Types of interrupts

Overview[edit]

Hardware interrupts were introduced as an optimization, eliminating unproductive waiting time in polling loops, waiting for external events. The first system to use this approach was the DYSEAC, completed in 1954, although earlier systems provided error trap functions.^[4] Interrupts may be implemented in hardware as a distinct system with control lines, or they may be integrated into the memory subsystem.

If implemented in hardware, an interrupt controller circuit such as the IBM PC's Programmable Interrupt Controller (PIC) may be connected between the interrupting device and the processor's interrupt pin to multiplex several sources of interrupt onto the one or two CPU lines typically available. If implemented as part of the memory controller, interrupts are mapped into the system's memory address space.

Interrupts can be categorized into these different types:

Maskable interrupt (IRQ): a hardware interrupt that may be ignored by setting a bit in an interrupt mask register's (IMR) bit-mask.
Non-maskable interrupt (NMI): a hardware interrupt that lacks an associated bit-mask, so that it can never be ignored. NMIs are used for the highest priority tasks such as timers, especially watchdog timers.
Inter-processor interrupt (IPI): a special case of interrupt that is generated by one processor to interrupt another processor in a multiprocessor system.
Software interrupt: an interrupt generated within a processor by executing an instruction. Software interrupts are often used to implement system calls because they result in a subroutine call with a CPU ring level change.
Spurious interrupt: a hardware interrupt that is unwanted. They are typically generated by system conditions such as electrical interference on an interrupt line or through incorrectly designed hardware.

Processors typically have an internal interrupt mask which allows software to ignore all external hardware interrupts while it is set. Setting or clearing this mask may be faster than accessing an interrupt mask register (IMR) in a PIC or disabling interrupts in the device itself. In some cases, such as the x86 architecture, disabling and enabling interrupts on the processor itself act as a memory barrier; however, it may actually be slower.

An interrupt that leaves the machine in a well-defined state is called a precise interrupt. Such an interrupt has four properties:

The Program Counter (PC) is saved in a known place.
All instructions before the one pointed to by the PC have fully executed.
No instruction beyond the one pointed to by the PC has been executed, or any such instructions are undone before handling the interrupt.
The execution state of the instruction pointed to by the PC is known.

An interrupt that does not meet these requirements is called an imprecise interrupt.

The phenomenon where the overall system performance is severely hindered by excessive amounts of processing time spent handling interrupts is called an interrupt storm.

History[edit]

The UNIVAC 1103 computer is generally credited with the earliest use of interrupts in 1953.^[5] Earlier, on the UNIVAC I (1951) 'Arithmetic overflow either triggered the execution a two-instruction fix-up routine at address 0, or, at the programmer's option, caused the computer to stop.' The IBM 650 (1954) incorporated the first occurrence of interrupt masking. The National Bureau of StandardsDYSEAC (1954) was the first to use interrupts for I/O. The IBM 704 was the first to use interrupts for debugging, with a 'transfer trap', which could invoke a special routine when a branch instruction was encountered.The MIT Lincoln LaboratoryTX-2 system (1957) was the first to provide multiple levels of priority interrupts.^[6]

Types of interrupts[edit]

Level-triggered[edit]

A level-triggered interrupt is an interrupt signaled by maintaining the interrupt line at a high or low logic level. A device wishing to signal a level-triggered interrupt drives the interrupt request line to its active level (high or low), and then holds it at that level until it is serviced. It ceases asserting the line when the CPU commands it to or otherwise handles the condition that caused it to signal the interrupt.

Typically, the processor samples the interrupt input at predefined times during each bus cycle such as state T2 for the Z80 microprocessor. If the interrupt isn't active when the processor samples it, the CPU doesn't see it. One possible use for this type of interrupt is to minimize spurious signals from a noisy interrupt line: a spurious pulse will often be so short that it is not noticed.

Multiple devices may share a level-triggered interrupt line if they are designed to. The interrupt line must have a pull-down or pull-up resistor so that when not actively driven it settles to its inactive state. Devices actively assert the line to indicate an outstanding interrupt, but let the line float (do not actively drive it) when not signalling an interrupt. The line is then in its asserted state when any (one or more than one) of the sharing devices is signalling an outstanding interrupt.

Level-triggered interrupt is favored by some because it is easy to share the interrupt request line without losing the interrupts, when multiple shared devices interrupt at the same time. Upon detecting assertion of the interrupt line, the CPU must search through the devices sharing the interrupt request line until one who triggered the interrupt is detected. After servicing this device, the CPU may recheck the interrupt line status to determine whether any other devices also need service. If the line is now de-asserted, the CPU avoids checking the remaining devices on the line. Since some devices interrupt more frequently than others, and other device interrupts are particularly expensive, a careful ordering of device checks is employed to increase efficiency. The original PCI standard mandated level-triggered interrupts because of this advantage of sharing interrupts.

There are also serious problems with sharing level-triggered interrupts. As long as any device on the line has an outstanding request for service the line remains asserted, so it is not possible to detect a change in the status of any other device. Deferring servicing a low-priority device is not an option, because this would prevent detection of service requests from higher-priority devices. If there is a device on the line that the CPU does not know how to service, then any interrupt from that device permanently blocks all interrupts from the other devices.

Edge-triggered[edit]

An edge-triggered interrupt is an interrupt signalled by a level transition on the interrupt line, either a falling edge (high to low) or a rising edge (low to high). A device, wishing to signal an interrupt, drives a pulse onto the line and then releases the line to its inactive state. If the pulse is too short to be detected by polled I/O then special hardware may be required to detect the edge.

Multiple devices may share an edge-triggered interrupt line if they are designed to. The interrupt line must have a pull-down or pull-up resistor so that when not actively driven it settles to one particular state. Devices signal an interrupt by briefly driving the line to its non-default state, and let the line float (do not actively drive it) when not signalling an interrupt. This type of connection is also referred to as open collector. The line then carries all the pulses generated by all the devices. (This is analogous to the pull cord on some buses and trolleys that any passenger can pull to signal the driver that they are requesting a stop.) However, interrupt pulses from different devices may merge if they occur close in time. To avoid losing interrupts the CPU must trigger on the trailing edge of the pulse (e.g. the rising edge if the line is pulled up and driven low). After detecting an interrupt the CPU must check all the devices for service requirements.

Edge-triggered interrupts do not suffer the problems that level-triggered interrupts have with sharing. Service of a low-priority device can be postponed arbitrarily, and interrupts will continue to be received from the high-priority devices that are being serviced. If there is a device that the CPU does not know how to service, it may cause a spurious interrupt, or even periodic spurious interrupts, but it does not interfere with the interrupt signalling of the other devices. However, it is fairly easy for an edge-triggered interrupt to be missed - for example, if interrupts have to be masked for a period - and unless there is some type of hardware latch that records the event it is impossible to recover. Such problems caused many 'lockups' in early computer hardware because the processor did not know it was expected to do something. More modern hardware often has one or more interrupt status registers that latch the interrupt requests; well-written edge-driven interrupt software often checks such registers to ensure events are not missed.

The elderly Industry Standard Architecture (ISA) bus uses edge-triggered interrupts, but does not mandate that devices be able to share them. The parallel port also uses edge-triggered interrupts. Many older devices assume that they have exclusive use of their interrupt line, making it electrically unsafe to share them. However, ISA motherboards include pull-up resistors on the IRQ lines, so well-behaved devices share ISA interrupts just fine.

Triggering[edit]

There are 3 ways multiple devices 'sharing the same line' can be raised. First is by exclusive conduction (switching) or exclusive connection (to pins). Next is by bus (all connected to same line listening): cards on a bus must know when they are to talk and not talk (ie, the ISA bus). Talking can be triggered two ways: by accumulation latch or by logic gate. Logic gates expect a continual data flow which is monitored for key signals. Accumulators only trigger when the remote side excites the gate beyond a threshold, thus no negotiated speed is required. Each has its speed versus distance advantages. A trigger, generally, is the method in which excitation is detected: rising edge, falling edge, threshold (oscilloscope can trigger upon a wide variety of shapes and conditions).

Triggering for software interrupts must be built into the software (both in OS and app). A 'C' app has a trigger table (a table of functions) in its header, which both the app and OS know of and use appropriately that is not related to hardware. However do not confuse this with hardware interrupts which signal the CPU (the CPU enacts software from a table of functions, similarly to software interrupts).

Hybrid[edit]

Some systems use a hybrid of level-triggered and edge-triggered signalling. The hardware not only looks for an edge, but it also verifies that the interrupt signal stays active for a certain period of time.

A common use of a hybrid interrupt is for the NMI (non-maskable interrupt) input. Because NMIs generally signal major – or even catastrophic – system events, a good implementation of this signal tries to ensure that the interrupt is valid by verifying that it remains active for a period of time. This 2-step approach helps to eliminate false interrupts from affecting the system.

Message-signaled[edit]

A message-signalled interrupt does not use a physical interrupt line. Instead, a device signals its request for service by sending a short message over some communications medium, typically a computer bus. The message might be of a type reserved for interrupts, or it might be of some pre-existing type such as a memory write.

Message-signalled interrupts behave very much like edge-triggered interrupts, in that the interrupt is a momentary signal rather than a continuous condition. Interrupt-handling software treats the two in much the same manner. Typically, multiple pending message-signalled interrupts with the same message (the same virtual interrupt line) are allowed to merge, just as closely spaced edge-triggered interrupts can merge.

Message-signalled interrupt vectors can be shared, to the extent that the underlying communication medium can be shared. No additional effort is required.

Because the identity of the interrupt is indicated by a pattern of data bits, not requiring a separate physical conductor, many more distinct interrupts can be efficiently handled. This reduces the need for sharing. Interrupt messages can also be passed over a serial bus, not requiring any additional lines.

PCI Express, a serial computer bus, uses message-signalled interrupts exclusively.

Doorbell[edit]

In a push button analogy applied to computer systems, the term doorbell or doorbell interrupt is often used to describe a mechanism whereby a software system can signal or notify a computer hardware device that there is some work to be done. Typically, the software system will place data in some well-known and mutually agreed upon memory location(s), and 'ring the doorbell' by writing to a different memory location. This different memory location is often called the doorbell region, and there may even be multiple doorbells serving different purposes in this region. It is this act of writing to the doorbell region of memory that 'rings the bell' and notifies the hardware device that the data are ready and waiting. The hardware device would now know that the data are valid and can be acted upon. It would typically write the data to a hard disk drive, or send them over a network, or encrypt them, etc.

The term doorbell interrupt is usually a misnomer. Its similar to an interrupt, because it causes some work to be done by the device; however, the doorbell region is sometimes implemented as a polled region, sometimes the doorbell region writes through to physical device registers, and sometimes the doorbell region is hardwired directly to physical device registers. When either writing through or directly to physical device registers, this may cause a real interrupt to occur at the device's central processor unit (CPU), if it has one.

Doorbell interrupts can be compared to Message Signaled Interrupts, as they have some similarities.

Difficulty with sharing interrupt lines[edit]

Multiple devices sharing an interrupt line (of any triggering style) all act as spurious interrupt sources with respect to each other. With many devices on one line, the workload in servicing interrupts grows in proportion to the square of the number of devices. It is therefore preferred to spread devices evenly across the available interrupt lines. Shortage of interrupt lines is a problem in older system designs where the interrupt lines are distinct physical conductors. Message-signalled interrupts, where the interrupt line is virtual, are favored in new system architectures (such as PCI Express) and relieve this problem to a considerable extent.

Some devices with a poorly designed programming interface provide no way to determine whether they have requested service. They may lock up or otherwise misbehave if serviced when they do not want it. Such devices cannot tolerate spurious interrupts, and so also cannot tolerate sharing an interrupt line. ISA cards, due to often cheap design and construction, are notorious for this problem. Such devices are becoming much rarer, as hardware logic becomes cheaper and new system architectures mandate shareable interrupts.

Performance issues[edit]

Interrupts provide low overhead and good latency at low load, but degrade significantly at high interrupt rate unless care is taken to prevent several pathologies. These are various forms of livelocks, when the system spends all of its time processing interrupts to the exclusion of other required tasks. Under extreme conditions, a large number of interrupts (like very high network traffic) may completely stall the system. To avoid such problems, an operating system must schedule network interrupt handling as carefully as it schedules process execution.^[7]

With multi-core processors, additional performance improvements in interrupt handling can be achieved through receive-side scaling (RSS) when multiqueue NICs are used. Such NICs provide multiple receive queues associated to separate interrupts; by routing each of those interrupts to different cores, processing of the interrupt requests triggered by the network traffic received by a single NIC can be distributed among multiple cores. Distribution of the interrupts among cores can be performed automatically by the operating system, or the routing of interrupts (usually referred to as IRQ affinity) can be manually configured.^[8]^[9]

A purely software-based implementation of the receiving traffic distribution, known as receive packet steering (RPS), distributes received traffic among cores later in the data path, as part of the interrupt handler functionality. Advantages of RPS over RSS include no requirements for specific hardware, more advanced traffic distribution filters, and reduced rate of interrupts produced by a NIC. As a downside, RPS increases the rate of inter-processor interrupts (IPIs). Receive flow steering (RFS) takes the software-based approach further by accounting for application locality; further performance improvements are achieved by processing interrupt requests by the same cores on which particular network packets will be consumed by the targeted application.^[8]^[10]^[11]

Typical uses[edit]

Typical uses of interrupts include the following: system timers, disk I/O, power-off signals, and traps. Other interrupts exist to transfer data bytes using UARTs or Ethernet; sense key-presses; control motors; or anything else the equipment must do.

Another typical use is to generate periodic interrupts by dividing the output of a crystal oscillator and having an interrupt handler count the interrupts in order for a processor to keep time. These periodic interrupts are often used by the OS's task scheduler to reschedule the priorities of running processes. Some older computers generated periodic interrupts from the power line frequency because it was controlled by the utilities to eliminate long-term drift of electric clocks.

For example, a disk interrupt signals the completion of a data transfer from or to the disk peripheral; a process waiting to read or write a file starts up again. As another example, a power-off interrupt predicts or requests a loss of power, allowing the computer equipment to perform an orderly shut-down. Also, interrupts are used in typeahead features for buffering events like keystrokes.

Interrupts are used to allow emulation of instructions which are unimplemented on certain models in a computer line.^[12] For example floating point instructions may be implemented in hardware on some systems and emulated on lower-cost systems. Execution of an unimplemented instruction will cause an interrupt. The operating system interrupt handler will recognize the occurrence on an unimplemented instruction, interpret the instruction in a software routine, and then return to the interrupting program as if the instruction had been executed.^[13] This provides application software portability across the entire line.

References[edit]