350 lines
24 KiB
TeX
350 lines
24 KiB
TeX
\chapter{Background}
|
|
\label{ch:background}
|
|
|
|
In this chapter, important domain-specific concepts will be explained, to create the necessary foundation to follow \autoref{ch:interrupthandling} and \autoref{ch:implementation}.
|
|
Important terms present in the glossary are marked in \textbf{bold} on their first occurrence.
|
|
|
|
\clearpage
|
|
|
|
\section{Handling of External Events}
|
|
\label{sec:eventhandling}
|
|
|
|
There are two different strategies to \textquote{listen} for external events: \textquote{Polling} and \textquote{Interrupts}.
|
|
|
|
The first strategy works by periodically \textit{polling} a device to check for changes.
|
|
This could mean reading a register of the keyboard every \SI{50}{\milli\second} to determine if a key was pressed, or reading a sensor output even when the value remains unchanged.
|
|
Because every device would have to be polled constantly, no matter if any change actually occurred, this method is computationally inefficient (although easy to implement without extra hardware).
|
|
|
|
The second strategy are \textit{interrupts}.
|
|
Instead of the CPU actively \textquote{looking} for changes, the devices signal the events to the CPU themselves.
|
|
Every time the CPU is notified of an external event, it pauses the current code execution and calls a function designated to handle this specific event.
|
|
|
|
This approach is much more efficient than the polling strategy, because the CPU does not have to waste its processing power to check for events when none are occurring.
|
|
|
|
\section{Fundamental Concepts}
|
|
\label{sec:fundamentals}
|
|
|
|
\subsection{Interrupt}
|
|
\label{subsec:interrupt}
|
|
|
|
When a device signals an external event to the CPU, the current code execution gets \textit{interrupted}, to handle the event.
|
|
|
|
Interrupts can be caused by all sorts of events, like key presses on a keyboard or packets received via a network card.
|
|
These interrupts from external hardware devices are called \textit{external interrupts}.
|
|
|
|
Other types of interrupts mentioned in this thesis are \textbf{\glspl{ipi}}, \textbf{\glspl{msi}} and \textbf{\glspl{local interrupt}}:
|
|
|
|
\begin{itemize}
|
|
\item IPIs: Interrupts sent between different processor cores in multiprocessor systems, e.g.\ to initialize different cores on system startup or synchronize caches.
|
|
\item MSIs: Interrupts sent in-band\footnote{
|
|
In in-band signaling, control information is sent over the same channel as the data, while out-of-band signaling uses a dedicated control line.},
|
|
\ e.g.\ over a PCI-bus\footnote{
|
|
PCI supports MSIs since PCI 2.2~\autocite[sec.~6.8]{pci22}.}.
|
|
\item Local Interrupts: Some specific CPU-internal interrupts, e.g.\ for performance monitoring.
|
|
\end{itemize}
|
|
|
|
Some interrupts are essential for CPU operation.
|
|
These \textbf{\glspl{nmi}} always have to be handled and cannot be ignored (except in some special cases, like booting).
|
|
Hardware error interrupts are a typical example for NMIs.
|
|
|
|
The existence of NMIs hints that it is possible to ignore regular interrupts.
|
|
Marking an interrupt as \textquote{ignored} is called \textit{masking} an interrupt.
|
|
|
|
\subsection{Interrupt Controller}
|
|
\label{subsec:controller}
|
|
|
|
A computer system has to process interrupts from many sources, so it is practical to have a designated \textit{interrupt controller}, that receives interrupts from different devices and forwards them to the CPU\@.
|
|
The masking functionality is integrated into the interrupt controller, so masked interrupts do not reach the CPU at all.
|
|
|
|
The interrupt controller receives interrupts through signals over physical connections (\textit{interrupt lines}) to different devices.
|
|
These signals can be represented in multiple ways through the level on the interrupt lines:
|
|
|
|
\textit{Trigger mode}:
|
|
|
|
\begin{itemize}
|
|
\item Edge-triggered: A signal is received when the interrupt line level changes.
|
|
\item Level-triggered: A signal is received when the interrupt line reaches a certain level.
|
|
\end{itemize}
|
|
|
|
\textit{Pin polarity}:
|
|
|
|
\begin{itemize}
|
|
\item Active-high: A signal is received when the interrupt line level changes from either low to high (in edge-triggered mode) or reaches a level above a threshold (in level-triggered mode).
|
|
\item Active-low: A signal is received when the interrupt line level changes from either high to low (in edge-triggered mode) or reaches a level below a threshold (in level-triggered mode).
|
|
\end{itemize}
|
|
|
|
A signal is represented through a combination of trigger mode and pin polarity, so there are a total of four combinations.
|
|
|
|
When the interrupt controller receives an interrupt signal, it requests the CPU to handle the specific event: The interrupt controller sends an \textbf{\gls{irq}} to the CPU\@.
|
|
Because there are multiple devices that can signal interrupts, an IRQ is usually indexed by its \textbf{\gls{inti}} on the interrupt controller: If a keyboard is connected to the interrupt controller on INTI1, the CPU receives an IRQ1.
|
|
|
|
To signal that an interrupt is being handled by the software, the interrupt controller receives an \textbf{\gls{eoi}} notice from the OS\@.
|
|
|
|
Information on specific interrupt controllers follows in \autoref{sec:intelcontrollers}.
|
|
|
|
\subsection{Interrupt Handler}
|
|
\label{subsec:handler}
|
|
|
|
When the CPU receives an IRQ, it pauses its current code execution to handle the interrupt (see \autoref{fig:interruptexecution}).
|
|
This is done by executing the \textit{interrupt handler} function, that is registered to the specific interrupt.
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\begin{subfigure}[b]{0.5\textwidth}
|
|
\includesvg[width=1.0\linewidth]{diagrams/interrupt_seq.svg}
|
|
\end{subfigure}
|
|
\caption{Interrupt Handler Execution.}
|
|
\label{fig:interruptexecution}
|
|
\end{figure}
|
|
|
|
During interrupt servicing (execution of the interrupt handler), other interrupts can occur.
|
|
When the execution of an interrupt handler is paused to handle another interrupt, this is called a \textit{cascaded interrupt}.
|
|
|
|
Interrupt handlers have to be registered to different IRQs, so the CPU can locate and execute the specific code that is designated to handle a certain interrupt.
|
|
The interrupt handler addresses are stored in an \textit{interrupt vector table}: Each address corresponds to an \textit{interrupt vector} number, interrupt vectors 0--31 are reserved for the CPU, interrupt vectors 32--255 are usable for IRQs.
|
|
In Intel's x86 IA-32 CPU architecture, this table is called the \textbf{\gls{idt}}.
|
|
The \textbf{\gls{idtr}} keeps the location of the IDT, it is written by the \code{lidt}~\autocite{x86isa} instruction.
|
|
|
|
\subsection{Interrupt Trigger Mode}
|
|
\label{subsec:triggermode}
|
|
|
|
When an edge-triggered IRQ is received, its interrupt handler is called a single time to service the interrupt, which does not require interacting with the device the interrupt originated from.
|
|
The handler of an edge-triggered IRQ is called every time the interrupt line changes its level (low-to-high or high-to-low, as specified by the pin polarity).
|
|
This could lead to problems if \textquote{glitches} occur on the interrupt line.
|
|
|
|
An alternative is the level-triggered IRQ\@: When the interrupt line is above/below a certain level, the interrupt is signaled continuously.
|
|
Servicing the interrupt thus requires not only notifying the interrupt controller (EOI), but also interaction with the device the interrupt originated from, to deassert the interrupt line.
|
|
Otherwise, the interrupt handler would be called again after completion.
|
|
|
|
\subsection{Spurious Interrupt}
|
|
\label{subsec:spurious}
|
|
|
|
When an interrupt \textquote{disappears} while the interrupt controller is issuing the IRQ, the interrupt controller sends a \textit{spurious interrupt}.
|
|
The reason for this could be electrical noise on the interrupt line, masking of an interrupt through software at the same moment the IRQ was dispatched, or incorrectly sent EOIs.
|
|
Thus, before an interrupt handler is called, the OS has to check the validity of the occurred interrupt and ignore it, if it is deemed spurious.
|
|
|
|
\section{Used Technologies}
|
|
\label{sec:technologies}
|
|
|
|
\subsection{Advanced Configuration and Power Interface}
|
|
\label{subsec:acpi}
|
|
|
|
\textbf{\gls{acpi}} allows the kernel to gather information about the system hardware during runtime.
|
|
It also provides interactive functionality for power management, plug and play, hot-swapping or status monitoring.
|
|
To interact with ACPI, the \textbf{\gls{aml}}~\autocite[sec.~16]{acpi1}, a small language interpreted by the kernel, has to be used\footnote{
|
|
In this thesis, information from ACPI is only read, so AML is not required.}.
|
|
|
|
ACPI defines abstractions for different types of hardware, that are organized in multiple \textit{system description tables}.
|
|
In this thesis, ACPI 1.0~\autocite{acpi1} is used to read information about the system's interrupt hardware configuration, located in the ACPI \textbf{\gls{madt}}~\autocite[sec.~5.2.8]{acpi1}.
|
|
The MADT contains information on used interrupt controllers (version, physical memory addresses to access registers, etc.), available CPU cores in multiprocessor systems and specific interrupt configuration (trigger mode and pin polarity).
|
|
|
|
To allow compatibility to different interrupt controllers, ACPI abstracts external interrupts through \textbf{\glspl{gsi}}~\autocite[sec.~5.2.9]{acpi1}.
|
|
Different interrupt controllers may have the same devices connected to different interrupt lines, maintaining a mapping between actual hardware interrupt lines and GSIs allows the OS to operate on different interrupt controllers\footnote{
|
|
Additional information in \autoref{subsec:ioapicpcat}.}.
|
|
|
|
\subsection{CPU Identification}
|
|
\label{subsec:cpuid}
|
|
|
|
\textbf{\gls{cpuid}} is used to gather information about a system's CPU\@.
|
|
The x86 architecture provides the \code{cpuid}~\autocite{x86isa} instruction, which allows the software to identify present CPU features at runtime, e.g.\ what instruction set extensions a processor implements\footnote{
|
|
This thesis uses CPUID to determine what APIC feature set is supported, see \textquote{APIC} and \textquote{x2APIC} features in the CPUID application note~\autocite[sec.~5.1.2]{cpuid}.}.
|
|
|
|
\subsection{Symmetric Multiprocessing}
|
|
\label{subsec:smp}
|
|
|
|
\textbf{\gls{smp}} is a form of multiprocessing, where a system consists of multiple, homogeneous CPU cores, that all have access to a shared main memory and the I/O devices.
|
|
SMP systems are controlled by a single OS, that treats all cores as individual, but equal processors.
|
|
The shared main memory allows every core to work on an arbitrary task, independent of its memory location.
|
|
Programming for SMP systems requires the usage of multithreading, to allow for an efficient distribution of tasks to multiple CPU cores.
|
|
|
|
In SMP systems, a single CPU core is active initially, this core is called the \textbf{\gls{bsp}}.
|
|
Other cores, called \textbf{\glspl{ap}}, will be initialized by this core.
|
|
|
|
% TODO: I think I could remove this section
|
|
% \subsection{BIOS and UEFI}
|
|
% \label{subsec:biosuefi}
|
|
%
|
|
% The \textbf{\gls{bios}} provides low-level control over a computer system's hardware, most commonly
|
|
% used for booting an OS on system power-up. Its pre-boot environment is limited to the 16-bit
|
|
% \textbf{\gls{real mode}} and 1 MB of addressable memory. BIOS originates from the IBM PC and has
|
|
% been the default convention for computer system firmware until the \textbf{\gls{uefi}} standard.
|
|
%
|
|
% The UEFI standard is developed by the UEFI Forum, based on Intel's EFI. It improves on BIOS by
|
|
% providing modularity, support for larger partitions, 32-bit or 64-bit environments before booting
|
|
% and advanced features like networking capabilities, graphical user interfaces with mouse support or
|
|
% security features\footnote{See \url{https://uefi.org/specifications} (visited on 22/02/2023).}.
|
|
|
|
\subsection{Model Specific Register}
|
|
\label{subsec:msr}
|
|
|
|
A \textbf{\gls{msr}} is a special control register in an IA-32 CPU, that is not guaranteed to be present in future CPU generations (it is not part of the architectural standard).
|
|
MSRs that carried over to future generations and are now guaranteed to be included in future IA-32 or Intel 64 CPUs are called \textquote{architectural} MSRs.
|
|
To interact with MSRs, the special instructions \code{rdmsr} and \code{wrmsr} are used~\autocite{x86isa}.
|
|
These instructions allow atomic read/write operations on MSRs\footnote{
|
|
Detailed description in the IA-32 manual~\autocite[sec.~4.2]{ia32}.}.
|
|
|
|
\subsection{Memory Mapped I/O}
|
|
\label{subsec:mmio}
|
|
|
|
\textbf{\gls{mmio}} is a way for the CPU to perform I/O operations with an external device.
|
|
Registers of external devices are mapped to the same address space as the main memory, thus a memory address can either be a location in physical memory, or belong to a device's register.
|
|
Read and write operations are then performed by reading or writing the address the register is mapped to.
|
|
|
|
\subsection{Programmable Interval Timer}
|
|
\label{subsec:pit}
|
|
|
|
The \textbf{\gls{pit}}~\autocite{pit} is a hardware timer from the original IBM PC\@.
|
|
It consists of multiple decrementing counters and can generate a signal (e.g.\ an interrupt) once 0 is reached.
|
|
This can be used to control a preemptive\footnote{
|
|
A scheduler is called \textquote{preemptive}, when it is able to forcefully take away the CPU from the currently working thread, even when the thread did not signal any form of completion.}
|
|
\ scheduler or the integrated PC speaker.
|
|
|
|
\section{Intel's Interrupt Controllers}
|
|
\label{sec:intelcontrollers}
|
|
|
|
Because it is logistically difficult to connect every external device directly to the CPU, this task is delegated to a dedicated interrupt controller.
|
|
Notable interrupt controllers (and the only ones considered in this thesis) are the Intel \textbf{\gls{pic}} and Intel \textbf{\gls{apic}}.
|
|
|
|
\subsection{Programmable Interrupt Controller}
|
|
\label{subsec:intelpic}
|
|
|
|
The Intel \textquote{8259A} PIC~\autocite{pic} is the interrupt controller Intel used in the original Intel \textquote{8086}\footnote{
|
|
The 8259 was used in the Intel \textquote{8080} and \textquote{8085}, the 8259A is a revised version for the Intel 8086},
|
|
\ the \textquote{father} of the x86 processor architecture.
|
|
A single PIC has eight interrupt lines for external devices, but multiple PICs can be cascaded for a maximum of \(8 \cdot 8 = 64\) interrupt lines with nine PICs.
|
|
The most common PIC configuration supports 15 IRQs with two PICs (see \autoref{fig:pcatpic}): A slave, connected to INTI2 of the master, which is connected to the CPU\footnote{
|
|
This configuration is called the \textquote{PC/AT PIC Architecture}, as it was used in the IBM PC/AT~\autocite[sec.~1.13]{pcat}.}.
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\begin{subfigure}[b]{0.3\textwidth}
|
|
\includesvg[width=1.0\linewidth]{img/mp_spec_pic_configuration.svg}
|
|
\end{subfigure}
|
|
\caption{The PC/AT PIC Architecture~\autocite[sec.~1.13]{pcat}.}
|
|
\label{fig:pcatpic}
|
|
\end{figure}
|
|
|
|
If multiple interrupts get requested simultaneously, the PIC decides which one to service first based on its \textit{interrupt priority}.
|
|
The PIC IRQ priorities are determined by the used interrupt lines, IRQ0 has the highest priority.
|
|
|
|
The PIC interrupt handling sequence can be briefly outlined as follows:
|
|
|
|
\begin{enumerate}
|
|
\item When the PIC receives an unmasked interrupt from a device (PIC interrupts are edge-triggered with high pin polarity), it sets the corresponding bit in its \textbf{\gls{irr}}\footnote{
|
|
Received IRQs that are requesting servicing are marked in the IRR.}.
|
|
\item The IRQ is dispatched to the CPU\@.
|
|
\item The CPU acknowledges the IRQ\@.
|
|
\item The PIC sets the corresponding bit in its \textbf{\gls{isr}}\footnote{
|
|
IRQs that are being serviced are marked in the ISR\@.
|
|
To reduce confusion, interrupt service routines will be denoted as \textquote{interrupt handler} instead of \textquote{ISR}.}
|
|
and clears the previously set bit in the IRR\@.
|
|
If the same interrupt occurs again, it can now be queued a single time in the IRR\@.
|
|
\item When the interrupt is being handled by the OS, it sends an EOI to the PIC, which clears the corresponding bit in the ISR\@.
|
|
\end{enumerate}
|
|
|
|
With the introduction of multiprocessor systems and devices with an ever-increasing need for large amounts of interrupts (like high-performance networking hardware), the PIC reached its architectural limits:
|
|
|
|
\begin{itemize}
|
|
\item Multiple CPU cores require sending IPIs for initialization and coordination, which is not possible using the PIC\@.
|
|
\item The PIC is hardwired to a single CPU core.
|
|
It can be inefficient to handle the entire interrupt workload on a single core.
|
|
\item The IRQ priorities depend on how the devices are physically wired to the PIC\@.
|
|
\item The PC/AT PIC architecture only has a very limited number of interrupt lines.
|
|
\item The PIC does not support MSIs, which allow efficient handling of PCI interrupts.
|
|
\end{itemize}
|
|
|
|
\subsection{Advanced Programmable Interrupt Controller}
|
|
\label{subsec:intelapic}
|
|
|
|
The original Intel \textquote{82489DX} \textbf{\gls{discrete apic}} was introduced with the Intel \textquote{i486} processor.
|
|
It consisted of two parts: A \textbf{\gls{local apic}}, responsible for receiving special \textbf{\glspl{local interrupt}}, and the \textbf{\gls{io apic}}, responsible for receiving external interrupts (and forwarding them to the local APIC).
|
|
Unlike in modern systems, the i486's local APIC was not integrated into the CPU core (hence \textquote{discrete}), see \autoref{fig:discreteapic}.
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\begin{subfigure}[b]{0.75\textwidth}
|
|
\includesvg[width=1.0\linewidth]{img/mp_spec_discrete_apic_configuration.svg}
|
|
\end{subfigure}
|
|
\caption{The Discrete APIC Architecture~\autocite[sec.~5.1]{mpspec}.}
|
|
\label{fig:discreteapic}
|
|
\end{figure}
|
|
|
|
The i486 was superseded by the Intel \textquote{P54C}\footnote{
|
|
The Intel P54C is the successor of the Intel P5, the first Pentium processor.},
|
|
\ which contained an \textit{integrated APIC} for the first time (see \autoref{fig:integratedapic}), which is now the default configuration.
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\begin{subfigure}[b]{0.75\textwidth}
|
|
\includesvg[width=1.0\linewidth]{img/mp_spec_integrated_apic_configuration.svg}
|
|
\end{subfigure}
|
|
\caption{The Integrated APIC Architecture~\autocite[sec.~5.2]{mpspec}.}
|
|
\label{fig:integratedapic}
|
|
\end{figure}
|
|
|
|
The APIC was designed to fix the shortcomings of the PIC, specifically regarding multiprocessor systems:
|
|
|
|
\begin{itemize}
|
|
\item Each CPU core contains its own local APIC\@.
|
|
It has the capabilities to handle local interrupts and IPIs, and communicate with the chipset I/O APIC\@.
|
|
\item The chipset I/O APIC allows configuration on a per-interrupt basis (priorities, destination, trigger mode or pin polarity are all configurable).
|
|
Also, it is able to distributes interrupts to different CPU cores, allowing the efficient processing of large amounts of interrupts\footnote{
|
|
There are tools that dynamically reprogram the I/O APIC to distribute interrupts to available CPU cores, depending on heuristics of past interrupts (IRQ-balancing).}.
|
|
\item The order in which external devices are connected to the I/O APIC is flexible.
|
|
\item The APIC architecture supports MSIs.
|
|
\end{itemize}
|
|
|
|
In comparison to the PIC, the external interrupt handling sequence changed:
|
|
|
|
\begin{enumerate}
|
|
\item An external interrupt arrives at the I/O APIC\@.
|
|
\item The I/O APIC redirects the interrupt to the local APIC, which sets the corresponding IRR bit.
|
|
\item The local APIC dispatches the IRQ\@.
|
|
\item The CPU acknowledges the IRQ and the local APIC sets the corresponding ISR bit.
|
|
\item When the interrupt is being handled by the OS, it sends an EOI to the local APIC\footnote{
|
|
In case of edge-triggered interrupts. For level-triggered interrupts see \autoref{subsec:ioapiceoi}.},
|
|
\ which clears the corresponding bit in the ISR\@.
|
|
Note how the OS only interacts directly with the local APIC, not the I/O APIC\@.
|
|
\end{enumerate}
|
|
|
|
To allow splitting the APIC architecture into local APICs of multiple CPU cores and I/O APICs, the individual components communicate over a bus.
|
|
In the Intel \textquote{P6} and \textquote{Pentium} processors a dedicated \textit{APIC bus} is used, but since the Intel \textquote{Pentium 4} and \textquote{Xeon} processors the \textit{system bus} is used instead (see \autoref{fig:systemvsapicbus})\footnote{
|
|
The Intel \textquote{Core} microarchitecture is based on the P6 architecture and replaces the Pentium 4's \textquote{NetBurst} architecture, but still uses the system bus instead of a discrete bus~\autocite[sec.~3.11.2]{ia32}.}.
|
|
Using the system bus is considered the default in this document.
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\begin{subfigure}[b]{0.6\textwidth}
|
|
\includesvg[width=1.0\linewidth]{img/ia32_manual_system_vs_apic_bus.svg}
|
|
\end{subfigure}
|
|
\caption{System Bus vs APIC Bus~\autocite[sec.~3.11.1]{ia32}.}
|
|
\label{fig:systemvsapicbus}
|
|
\end{figure}
|
|
|
|
Because the order in which external devices are connected to the interrupt controller is flexible in the APIC architecture, but fixed in the PC/AT PIC architecture, there can be deviations in device-to-IRQ mappings between the PIC and APIC interrupt controllers.
|
|
To handle this, ACPI provides information about how the PC/AT compatible interrupts (IRQ0 to IRQ15) map to ACPI's GSIs in the MADT, which has to be taken into account by the OS when operating with an APIC\@.
|
|
The mapping information for a single interrupt will be called \textbf{\gls{irq override}}.
|
|
|
|
There have been different revisions on the APIC architecture after the original, discrete APIC, notably the \textbf{\gls{xapic}} and \textbf{\gls{x2apic}} architectures.
|
|
This thesis is mostly concerned about the older xApic architecture\footnote{
|
|
This does not present a compatibility issue, as the x2Apic architecture is backwards compatible to the xApic architecture.}.
|
|
A notable difference between xApic and x2Apic architectures is the register access: xApic uses \SI{32}{\bit} MMIO based register access, while x2Apic uses an MSR based register access, which allows atomic register access to the \SI{64}{\bit} wide APIC control MSRs~\autocite[sec.~3.11.12]{ia32}.
|
|
|
|
\section{PC/AT Compatibility}
|
|
\label{sec:pcatcompat}
|
|
|
|
For compatibility with older computer systems, two cascaded PICs are usually present in current computer systems (see \autoref{fig:discreteapic}/\autoref{fig:integratedapic}).
|
|
The local APIC can be initialized to operate with these PICs instead of the I/O APIC, this is called \textbf{\gls{virtual wire mode}}~\autocite[sec.~3.6.2.2]{mpspec}.
|
|
It is possible to operate with both the PIC and I/O APIC as controllers for external interrupts in \textit{mixed mode}~\autocite[sec.~3.6.2.3]{mpspec}, but this is very uncommon.
|
|
Because the presence of a local APIC usually guarantees the presence of an I/O APIC, this thesis only focuses on interrupt handling with either two PICs with a single processor (\textbf{\gls{pic mode}}~\autocite[sec.~3.6.2.1]{mpspec}), in case no APIC is available, or the full APIC architecture (local APIC and I/O APIC in \textbf{\gls{symmetric io mode}}~\cite[sec.~3.6.2.3]{mpspec}).
|
|
Hardware following the MultiProcessor Specification must either implement PIC mode or virtual wire mode for PC/AT compatibility.
|
|
|
|
To switch from PIC mode (if implemented) to symmetric I/O mode, the \textbf{\gls{imcr}}, a special register which controls the physical connection of the PIC to the CPU, has to be configured.
|
|
In the original discrete APIC architecture, the IMCR can choose if either the PIC or local APIC is connected to the CPU (see \autoref{fig:discreteapic}), since the xApic architecture the IMCR only connects or disconnects the PIC to the local APIC's LINT0 INTI (see \autoref{fig:integratedapic}).
|
|
When the IMCR is set to connect the PIC, and the xApic \textquote{global enable/disable} flag is unset (see \autoref{subsec:lapicenable}), the system is functionally equivalent to an IA-32 CPU without an integrated local APIC~\autocite[sec.~3.11.4.3]{ia32}.
|
|
Modern systems (and QEMU) do not support PIC Mode and thus do not have the IMCR\@.
|
|
PC/AT compatibility is usually achieved in these systems by connecting two PICs to the first external interrupt input of the I/O APIC (see \autoref{fig:integratedapic}).
|
|
|
|
Specifics on handling PC/AT compatible external interrupts follow in \autoref{subsec:ioapicpcat}.
|
|
|
|
\cleardoublepage |