任务门,中断门,呼叫门

时间:2011-07-13 17:50:07

标签: linux-kernel x86 x86-64

我一直在尝试阅读有关x86架构中不同门的更多信息。如果我理解正确,那么中断和陷阱门分别用于hw和sw中断处理。 而CALL门可能不再使用,因为ppl更喜欢被SYSENTER和SYSEXIT取代。

我想知道如何使用任务门(我知道它们用于hw任务切换)。这究竟意味着什么? hw任务是否涉及OS任务/进程。或者更像是在两个不同的操作系统实例之间切换。 (可能在服务器上。)?

另一方面,可能会发生某些中断在用户模式下处理。 (我们可以在用户模式下处理除零中断。如果可以,那么这意味着除以零的IDT处理程序条目包含来自用户空间的地址吗?)

由于

2 个答案:

答案 0 :(得分:7)

您可能想知道关于中断和门的所有内容都在Intel developer manual, volume 3中。简而言之:

  • 任务门最初设计为CPU介导的执行任务切换的方法; CPU可以在任务切换操作期间自动记录进程的状态。这些通常不用于现代操作系统;操作系统通常会自行执行状态保存操作。
  • 至少在Linux中,所有中断处理程序都在内核空间中并在环0处执行。如果要处理除零异常,则为SIGFPE注册用户空间信号处理程序;内核空间中断处理程序引发SIGFPE信号,间接触发用户空间处理程序代码(从中断处理程序返回后执行用户空间代码)。

答案 1 :(得分:4)

事态是只有中断和陷阱门实际上在使用并且现在继续使用。从理论上讲,它们都可以用于s / w和h / w事件处理。它们之间的唯一区别是中断门控调用会自动禁止将来的中断,这在某些硬件中断处理的情况下很有用。 默认情况下,人们会尝试使用陷阱门,因为不必要的中断禁用是一件坏事,因为中断禁用会增加中断处理延迟并增加中断丢失的可能性。 呼叫门从未实际使用过。这是不方便的,也不是系统调用实现的最佳方式。而是调用gate,大多数操作系统使用陷阱门(Linux中的int 0x80和Windows中的int 0x2E)或sysenter / sysexit syscall / sysrt指令。 任务门从未实际使用过。它不是最佳,不方便和有限的功能,如果不是丑陋的话。操作系统通常通过内核模式任务堆栈切换来实现任务切换,而不是它。 最初,英特尔通过引入TSS(任务状态段)和任务门提供了多任务处理的硬件支持。根据该功能,处理器能够自动存储一个任务的状态并恢复另一个任务的状态以回复来自hw或sw的请求。可以通过发出带有TSS选择器或任务门选择器作为指令操作数的调用或jmp指令来完成Sw请求。 Hw请求可以通过硬件在适当的IDT条目中进入任务门来完成。但正如我已经提到的,没有人真正使用它。而不是它,操作系统只对所有任务使用一个TSS(在任何情况下都必须使用TSS,因为在从较低权限段到更多特权段CPU交换机堆栈的控制传输期间,它会捕获更多特权段的堆栈地址TSS)并手动进行任务切换。

理论上,可以在用户模式(环3)中处理中断和异常,但实际上它并没有用,操作系统在内核端(在环0中)处理所有这些事件。原因很简单,中断和异常处理程序必须始终驻留在内存中,并且可以从任何地址空间访问。地址空间的内核部分是共享的,并且在系统中所有任务的所有地址空间中都是相同的,但地址空间的用户部分连接到特定任务。如果要在用户模式下处理异常,则将强制在每个任务切换上重新编程IDT,这将导致显着的性能损失。如果要以相同的方式处理中断,则必须在相同地址的所有任务之间共享中断处理程序。作为不必要的后果,系统中的任何任务都将能够破坏处理程序。