Interruptions or IRQ: How Your CPU Manages Requests from the PC

CPUs do nothing but process programs sequentially, but we are so intrusive that we are continually causing them to stop running the program and interrupt them. How? Well, when you press a key, move the mouse. In this article we are going to explain how interrupt or IRQ requests work.

An interrupt request or better known as IRQ, which stands for Interrupt ReQuest, is an indispensable mechanism in every CPU to be able to interact with it at all levels, both by users and by the rest of the hardware.

Interruptions or IRQ

What are interrupt requests or IRQs?

What a CPU does is execute a program sequentially, but suddenly we press a key and see it printed on the screen. In a very short time the CPU had to stop the main program and attend to the request of the keyboard to print said letter on the screen, so there has been an interruption of the main execution thread. This phenomenon of interrupting a CPU is called an interrupt request or IRQ.

Render CPU Código

Interrupt requests or IRQs are generally signals sent by the CPU by external devices, especially peripherals connected to the I / O ports. How interrupts are handled depends on their source, but in terms of hardware they occur when a peripheral or component requires the attention of the CPU. It may be that they need to exchange data with the CPU through the common, coherent memory space, or they warn that a task they were doing has already been completed.

Hardware interrupt requests are divided into two different types:

  • Maskable interrupts: In the case of multiple interrupt requests, these are the ones that have the least preference when it comes to being resolved.
  • Non-maskable interruptions: When there are several interruptions at the same time, these are the ones that have the highest preference when it comes to being solved.

Interrupt requests or IRQ via software

petición interrupción software

The software can also generate interrupts through the operating system routine, this is done through a “system call”. On any computer running an advanced operating system, the operating system must be able to invoke the CPU interrupt system if necessary.

The reason for this is that this is necessary in order to manage access to multitasking programs, since each program is a different thread that could be executed in a different kernel. Now, count the number of open applications and the cores of your CPU and you will see that not all of them can be managed at the same time, that is why the operating system interrupts a thread of execution of a program to start another.

In the case of background applications, these leave their current state in the system RAM, but are always ready to be invoked again through a system call. With SSDs and the unification of addressing between SSD and memory, it will be possible to send the applications in the background to the SSD and invoke them as they were.

How does a CPU handle an interrupt request or IRQ?

Mecanismo interrupciones

To manage an interrupt request, the CPU has to stop the instruction cycle in its tracks. Every time an instruction is completed, the CPU itself will check if there is an interrupt request. In the event that it does not exist, it will execute the following line of program code. If it exists, what it will do is store the state of the program in a special register. The state being the value of the next instruction in the program counter.

Depending on the type of instruction, the CPU will load in the program counter a special memory address that points to the instruction ROM, a program in a memory apart from the processor that has coded how the CPU has to manage said instruction. The non-maskable instructions take precedence and once the interrupt process has been executed from the register in which the program counter value is stored, it is copied to it to continue with the usual execution.

The FLAGS of a CPU

FLAGS x86

Every CPU has a series of single-bit registers that indicate when certain phenomena occur, the FLAGS in CPUs with ISA x86 can be seen in the image above well described. All of them are summarized in a 32-bit wide register, where each bit represents a different state of the CPU.

In the case of x86 it is necessary that a hardware device called PIC, Programmable Interrupt Controller, to which the different peripherals are connected, is responsible for carrying out interrupt requests. This middleman was originally a separate chip and was designed to decrease the number of interfaces to the CPU, but with the adoption of the I / O controller in modern CPUs it has become part of the SoC.

It is therefore the PIC, which is remotely responsible for sending interrupt requests to the CPU, for this it only needs the signal that activates one of the bits of the processor’s FLAGS register. But if we look closely we will see that there are three bits that manage interruptions: Interrupt Enable Flag in bit 9, Virtual Interrupt Flag in bit 19 and Virtual Interrupt Pending in bit 20.

Virtual Interrupts

interrupción IRQ Virtual

Many contemporary systems make use of virtual machines, this means that the operating system is not the closest and most privileged software to the processor but the hypervisor on which it is running. This causes a conflict when it comes to handling interrupts at the software level. The solution? Give the hypervisor a higher hierarchy and create additional FLAGS. The Interrupt Enable Flag is activated when an operating system is executed without a hypervisor underneath and therefore alone. In the event that there is a hypervisor, it is the hypervisor itself that has priority over the Interrupt Enable Flag.

If an operating system is virtualized, then the bit that will be set is the Virtual Enable Flag. The reason for this separation is that at all times the different operating systems that are running see the peripherals differently and hence the need for separate interruption management. Basically when activating the Virtual Enable Flag what it does is remind the CPU that it is the threads of execution related to the virtual machine that have to be stopped to handle the interruption and not others.