中断执行上下文

Question

我正试图弄清楚这个基本情况：
假设我的cpu收到异常或中断。我所知道的是，cpu开始执行中断服务程序（查看idtr寄存器以找到idt表，并转到相应的条目以接收isr地址），但代码在什么上下文中运行？

这意味着如果我当前正在运行一个线程并生成某种类型的中断，isr运行的上下文，在“保持”线程的初始进程中，还是在其他一些神奇的线程中运行？

谢谢！

Answer 1

有趣的问题，引发了一些不同的问题。

首先，从CPU的角度来看，中断实际上并不在任何线程内部运行。实际上，CPU本身几乎不了解线程;如果它具有超线程或类似的技术，它可能会知道更多，但是线程实际上是操作系统的东西（或者，有时候，应用程序的东西）。

第二个问题是，ISR（中断服务例程）通常以某种提升的特权级别运行;你真的没有说你正在谈论哪个处理器系列，所以很难具体，但是现代处理器通常至少有一种特殊模式可以用来处理中断 - 通常有自己的寄存器库。作为问题的一部分，有人可能会问，在中断期间哪个页面表处于活动状态？

第三个是输入时ISR具有的存储器映射的问题。同样，答案将是高度处理器特定的;可以想象在ISR条目上禁用分页的体系结构，自动切换到中断页表的其他体系结构，以及（可能是最常用的方法）那些在进入ISR时决定不对页表做任何事情的方法。

第四是某些操作系统在这些事情上都有自己的策略。现代操作系统的一种常见方法是使ISR本身尽可能短，并且在需要完成任何重要工作的情况下，将中断转换为可由内核线程处理的某种事件（或者甚至可能由用户线程）。在这种系统中，实际处理中断的代码可能正在特定的线程中运行，尽管在那时它实际上可能不是一个中断服务程序。

要点：

• ISR本身不会真正在任何给定线程的上下文中运行。
• ISR 可以运行中断线程的页表（取决于架构）。
• ISR 可能从该线程的寄存器副本开始（取决于架构）。
• 在现代系统中，ISR通常会尝试安排事件，然后快速退出。该事件可能由特定线程处理（例如，对于处理器异常，它通常作为信号或结构化异常传递或类似于导致它的线程）;或者由一个线程池（例如，为内核中的I / O服务）。

如果你对x86的细节感兴趣（我猜你是，因为你在问题中使用了一些英特尔特定术语），你需要查看Intel 64 and IA-32 Architectures Software Developer’s Manual，第3B卷，和您需要查看操作系统文档。与其他一些架构相比，x86是一个非常复杂的架构 - 例如，它可以可选地执行中断传递的任务切换（如果你在IDT中放置一个“任务门”），在这种情况下，它将当然有自己的寄存器集，很可能是自己的页表;即使给定操作系统使用此功能，也无法保证x86任务直接（或根本）映射到操作系统进程和/或线程。