CODEWITHSUNDEEP
linuxprocesscpuinterruptinterrupt-handling
user18307826
user18307826

Reputation:

Linux: Interrupt handling: Who saves the context of interrupted process (some software (interrupt handler) or hardware (CPU itself))?

When an interrupt comes to CPU then who saves the context of the interrupted process (some software (interrupt handler) or hardware (CPU itself))?

As far as I understand, software (interrupt handler) cannot save the context of the interrupted process because if this software (interrupt handler) is running then the Instruction Pointer Register will have the address of this software's (interrupt handler) instruction and not of the interrupted process. So, this software (interrupt handler) will not know what was the value in the Instruction Pointer Register for the interrupted process.

So, I think that there is some hardware (in CPU or the CPU itself) that saves the context of the interrupted process because the hardware (in CPU or the CPU itself) can directly access the Instruction Pointer Register which will contain the instruction address of the interrupted process.

Am I right or wrong? Please let me know the details if someone knows.

Upvotes: 1

Views: 504

Answers (1)

beeselmane
beeselmane

Reputation: 1218

Both the CPU itself and the kernel are responsible for saving parts of the current userspace context. This is mostly an x86_64/amd64 specific answer, and the source for interrupt calls can be found mainly here and here. The hardware side of interrupt calls is described precisely in section 6 here.

Effectively, when an interrupt occurs in full 64-bit mode, the CPU will automatically switch the stack pointer into a predefined (via special hardware registers) 'interrupt stack.' Then, the stack pointer from the old user stack is pushed, along with the contents of SS, CS, RFLAGS, RIP, and the error code for the generated interrupt. Also, a privilege level change occurs automatically and the CPU jumps to a predetermined location from the Interrupt Descriptor Table (IDT), which the kernel sets up at boot time. The code to declare these entry points are in the first source file linked above. On the other side of the interrupt call (where execution continues in the kernel), the remaining state of the user process is saved to the extent necessary (depending on the interrupt itself) by pushing various registers to the interrupt stack. The interrupt is then serviced by calling a handler in C, and the user process is resumed once the handler returns (or not if there is some side effect of the specific interrupt). You can see the functions which are called in the second link above. That's a general overview. You're generally right about the CPU handling some things like the instruction pointer or original stack pointer, and then general purpose registers or other state is handled from the kernel side.

Upvotes: 1

Related Questions