Linux：中断处理：谁保存中断进程的上下文（某些软件（中断处理程序）或硬件（CPU本身））？
当中断到达 CPU 时，谁保存被中断进程的上下文（某些软件（中断处理程序）或硬件（CPU 本身））？
据我了解，软件（中断处理程序）无法保存被中断进程的上下文，因为如果该软件（中断处理程序）正在运行，那么指令指针寄存器将具有该软件（中断处理程序）指令的地址，而不是该软件（中断处理程序）指令的地址。中断的进程。因此，该软件（中断处理程序）将不知道中断进程的指令指针寄存器中的值是什么。
所以，我认为有一些硬件（在CPU或CPU本身）保存中断进程的上下文，因为硬件（在CPU或CPU本身）可以直接访问指令指针寄存器，其中将包含指令地址被中断的进程。
我是对还是错？如果有人知道请告诉我详细信息。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
CPU 本身和内核都负责保存当前用户空间上下文的部分内容。这主要是x86_64/amd64特定的答案，中断调用的来源主要可以找到 此处 这里。中断调用的硬件方面在第 6 节中进行了精确描述 此处。
实际上，当在全 64 位模式下发生中断时，CPU 会自动将堆栈指针切换到预定义的（通过特殊硬件寄存器）“中断堆栈”。然后，将旧用户堆栈中的堆栈指针以及
SS、CS、RFLAGS、RIP< 的内容一起压入。 /code>，以及生成的中断的错误代码。此外，特权级别更改会自动发生，CPU 会从内核在启动时设置的中断描述符表 (IDT) 跳转到预定位置。声明这些入口点的代码位于上面链接的第一个源文件中。在中断调用的另一侧（在内核中继续执行），通过将各种寄存器推送到中断堆栈来将用户进程的剩余状态保存到必要的程度（取决于中断本身）。然后通过调用 C 中的处理程序来处理中断，并且一旦处理程序返回（或者如果特定中断有一些副作用，则不会恢复），用户进程就会恢复。您可以看到上面第二个链接中调用的函数。这是一个总体概述。关于 CPU 处理指令指针或原始堆栈指针等一些事情，您通常是正确的，然后从内核端处理通用寄存器或其他状态。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 theInterrupt 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.