Documentation/x86/entry_64.txt

Chinese translated version of Documentation/x86/entry_64.txt

If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.

Chinese maintainer:Luo Yangyang <794436342@qq.com>
---------------------------------------------------------------------
Documentation/x86/entry_64.txt的中文翻译

如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。

中文版维护者： 罗秧秧  <794436342@qq.com>
中文版翻译者： 罗秧秧  <794436342@qq.com>
中文版校译者： 罗秧秧  <794436342@qq.com>

以下为正文
---------------------------------------------------------------------

This file documents some of the kernel entries in
arch/x86/kernel/entry_64.S.  A lot of this explanation is adapted from
an email from Ingo Molnar:

http://lkml.kernel.org/r/<20110529191055.GC9835%40elte.hu>

此文件记录了一些在arch/x86/kernel/entry_64.S中的
内核条目。有诸多这样的解释是改编自
一封来自Ingo Molnar的邮件：

http://lkml.kernel.org/r/ < 20110529191055.GC9835 ％ 40elte.hu >

The x86 architecture has quite a few different ways to jump into
kernel code.  Most of these entry points are registered in
arch/x86/kernel/traps.c and implemented in arch/x86/kernel/entry_64.S
and arch/x86/ia32/ia32entry.S.

x86架构有相当多的不同的方式进入
内核编码。这些入口点大多数在
arch/x86/kernel/traps.c中被注册,并且在arch/x86/kernel/entry_64.S
和arch/x86/ia32/ia32entry.S中被实现 。

The IDT vector assignments are listed in arch/x86/include/irq_vectors.h.
Some of these entries are:
 - system_call: syscall instruction from 64-bit code.
 - ia32_syscall: int 0x80 from 32-bit or 64-bit code; compat syscall
   either way.
 - ia32_syscall, ia32_sysenter: syscall and sysenter from 32-bit
   code
 - interrupt: An array of entries.  Every IDT vector that doesn't
   explicitly point somewhere else gets set to the corresponding
   value in interrupts.  These point to a whole array of
   magically-generated functions that make their way to do_IRQ with
   the interrupt number as a parameter.
 - APIC interrupts: Various special-purpose interrupts for things
   like TLB shootdown.
 - Architecturally-defined exceptions like divide_error.

IDT（中断描述符表）向量分配是在arch/x86/include/irq_vectors.h中被列出的。
其中的一些条目是：
 - system_call：64位编码的系统调用指令。
 - ia32_syscall ：32位或64位编码的INT 0x80; 任意方式的兼容性系统调用。
 - ia32_syscall，ia32_sysenter ：32位编码的系统调用和快速系统调用。
 - 中断：条目的数组。每个不
   明确指向别的地方的IDT向量被设置成相应的
   在中断值。这些指向 magic标记化的生成函数的整组，

   最后使do_IRQ以中断号作为参数。

 - APIC中断：给像TLB（页表缓冲）击落这样的各种特殊用途
   的中断。
 （在一个多处理器系统中,当一个处理器改变了一个页表或页目录的条目,
  这个改变必须要通知所有其它的处理器。这个过程通常称为"TLB shootdown"。）
 - 总体定义异常，如divide_error 。

There are a few complexities here.  The different x86-64 entries
have different calling conventions.  The syscall and sysenter
instructions have their own peculiar calling conventions.  Some of
the IDT entries push an error code onto the stack; others don't.
IDT entries using the IST alternative stack mechanism need their own
magic to get the stack frames right.  (You can find some
documentation in the AMD APM, Volume 2, Chapter 8 and the Intel SDM,
Volume 3, Chapter 6.)

在这里有一些复杂性。不同的x86-64的条目
有不同的调用约定。系统调用和快速系统调用
指令有它们自己特有的调用约定。一些
IDT条目将错误代码推入堆栈;另外一些不这样。
使用IST替代堆栈机制的IDT条目需要有自己
magic标记来获取堆栈帧的权利。 （你可以在文档AMD APM ，
第2卷，第8章和Intel SDM ，第3卷，第6章中找到一些参考资料。）

Dealing with the swapgs instruction is especially tricky.  Swapgs
toggles whether gs is the kernel gs or the user gs.  The swapgs
instruction is rather fragile: it must nest perfectly and only in
single depth, it should only be used if entering from user mode to
kernel mode and then when returning to user-space, and precisely
so. If we mess that up even slightly, we crash.

处理swapgs指令尤其棘手。无论GS是内核GS还是用户GS，Swapgs都会切换。 
这swapgs指令是相当脆弱不稳定的：它必须完美嵌套，只有在惟一的深度下，
它应该只被使用在从用户模式进入内核模式，然后返回到用户空间的时候，
的确是这样的。如果我们轻微地把它搞砸了，我们就失败了。

So when we have a secondary entry, already in kernel mode, we *must
not* use SWAPGS blindly - nor must we forget doing a SWAPGS when it's
not switched/swapped yet.

Now, there's a secondary complication: there's a cheap way to test
which mode the CPU is in and an expensive way.

所以，当我们已经有一个在内核模式下的二次项时，我们
*绝不能*盲目地使用SWAPGS - 当它尚未被改变/被交换时，
我们也不能忘记进行SWAPGS。

现在，有一个次要的并发症：有一种廉价的
方式和一种昂贵的方式来测试CPU处在哪种??模式下。

The cheap way is to pick this info off the entry frame on the kernel
stack, from the CS of the ptregs area of the kernel stack:
xorl %ebx,%ebx
testl $3,CS+8(%rsp)
je error_kernelspace
SWAPGS

The expensive (paranoid) way is to read back the MSR_GS_BASE value
(which is what SWAPGS modifies):
movl $1,%ebx
movl $MSR_GS_BASE,%ecx
rdmsr
testl %edx,%edx
js 1f   /* negative -> in kernel */
SWAPGS
xorl %ebx,%ebx
1: ret

and the whole paranoid non-paranoid macro complexity is about whether
to suffer that RDMSR cost.

廉价的方式是从内核堆栈ptregs区的代码段中
选择内核堆栈上的入口帧的信息：
        xorl %ebx,%ebx
testl $3,CS+8(%rsp)
je error_kernelspace
SWAPGS

昂贵的（偏执的）方式是回读MSR_GS_BASE的值
（这是SWAPGS修改的地方）：
        movl $1,%ebx
movl $MSR_GS_BASE,%ecx
rdmsr
testl %edx,%edx
js 1f   /* negative -> in kernel */
SWAPGS
xorl %ebx,%ebx
1: ret

并且整个偏执的非偏执的宏复杂性与是否
受到RDMSR代价有关。

If we are at an interrupt or user-trap/gate-alike boundary then we can
use the faster check: the stack will be a reliable indicator of
whether SWAPGS was already done: if we see that we are a secondary
entry interrupting kernel mode execution, then we know that the GS
base has already been switched. If it says that we interrupted
user-space execution then we must do the SWAPGS.

如果我们在一个中断或user-trap/gate-alike边界，那么我们可以
使用更快的检查：堆栈将会是一个判断SWAPGS是否已经完成的
可靠的指标：如果我们知道我们是一个使内核模式执行中断的
次要条目，那么我们就知道了GS基数已经被切换。如果说，我们使
用户空间执行被中断，那么我们就必须执行SWAPGS。

But if we are in an NMI/MCE/DEBUG/whatever super-atomic entry context,
which might have triggered right after a normal entry wrote CS to the
stack but before we executed SWAPGS, then the only safe way to check
for GS is the slower method: the RDMSR.

但是，如果我们是在NMI/MCE/DEBUG/whatever超原子项
上下文中时，刚好在一个正常的条目写CS到堆栈后，
但在我们执行SWAPGS之前可能已经触发，那么检查
GS的唯一安全方式是更慢的方式：RDMSR。

So we try only to mark those entry methods 'paranoid' that absolutely
need the more expensive check for the GS base - and we generate all
'normal' entry points with the regular (faster) entry macros.

因此，我们尝试只标记那些'偏执'的输入法，绝对
需要为GS基数进行更昂贵的检查 - 并且我们生成所有
带有更常规（更快）切入宏的“正常”切入点。