我在x86 CentOS 6.3(内核v2.6.32)系统上运行。
我将以下功能编译为准字符驱动程序模块,以进行实验,以了解Linux内核如何对浮点运算作出反应。
static unsigned floatstuff(void){ float x = 3.14; x *= 2.5; return x; } ... printk(KERN_INFO "x: %u", x);
代码已编译(没想到),因此我插入了模块,并使用来检查日志dmesg。日志显示:x: 7。
dmesg
x: 7
这似乎很奇怪;我以为您不能在Linux内核中执行浮点运算-保存一些异常,例如kernel_fpu_begin()。模块如何执行浮点运算?
kernel_fpu_begin()
这是因为我在x86处理器上吗?
我以为您不能在Linux内核中执行浮点运算
您不能 放心 :不使用kernel_fpu_begin()/ kernel_fpu_end()并不表示FPU指令会出错(至少不是在x86上)。
kernel_fpu_end()
相反,它将以静默方式破坏用户空间的FPU状态。这是不好的; 不要那样做
编译器不知道是什么kernel_fpu_begin()意思,因此它无法检查/警告有关在FPU开始区域之外编译为FPU指令的代码。
可能存在一种调试模式,其中内核确实在kernel_fpu_begin/ end区域之外禁用SSE,x87和MMX指令,但这会比较慢,并且默认情况下不会执行此操作。
kernel_fpu_begin
end
但是,这是可能的:设置CR0::TS = 1会使x87指令出错,因此可以进行懒惰的FPU上下文切换,并且SSE和AVX还有其他位。
CR0::TS = 1
有问题的内核代码有 很多 方法可以引起严重的问题。这只是众多之一。在C语言中,您几乎总是知道何时使用浮点数(除非输入错误会导致1.常量或实际编译的上下文中的东西)。
1.
FP架构状态为何与整数不同?
Linux必须在每次进入/退出内核时保存/恢复整数状态。所有代码都需要使用整数寄存器(FPU计算的巨型直线块以a jmp而不是a ret(ret修饰rsp)结尾)。
jmp
ret
rsp
但是内核代码通常会避免使用FPU,因此Linux会将FPU状态保留为从系统调用进入时未保存的状态,仅在实际上下文切换到其他 用户空间 进程之前保存kernel_fpu_begin。否则,通常会在相同的内核上返回相同的用户空间进程,因此无需恢复FPU状态,因为内核没有碰到它。(这就是如果一个内核任务实际上做了修改FPU状态腐败会发生,我认为这是双向的:用户空间也可能会破坏 你的 FPU状态)。
整数状态非常小,只有16个64位寄存器+ RFLAGS和段寄存器。即使没有AVX,FPU状态也要大两倍:8个80位x87寄存器,16个XMM或YMM或32个ZMM寄存器(+ MXCSR和x87状态+控制字)。MPX bnd0-4寄存器也与“ FPU”集中在一起。此时,“ FPU状态”仅表示所有非整数寄存器。在我的Skylake上dmesg说x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.
bnd0-4
x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.
请参阅了解Linux内核中FPU的用法。现代Linux默认情况下不对上下文切换执行惰性FPU上下文切换(仅用于内核/用户转换)。(但是那篇文章解释了什么是懒惰。)
大多数进程使用SSE复制/归零编译器生成的代码中的小块内存,大多数库字符串/ memcpy / memset实现使用SSE / SSE2。而且,硬件支持的优化保存/恢复现在已经成为xsaveopt现实(/ xrstor),因此,如果尚未实际使用某些/所有FP寄存器,“急切”的FPU保存/恢复实际上可能会减少工作量。例如,如果将它们清零,则仅保存YMM寄存器的低128b,vzeroupper以便CPU知道它们是干净的。(并以保存格式中的一位来标记该事实。)
xsaveopt
vzeroupper
通过“紧急”上下文切换,FPU指令始终保持启用状态,因此不良的内核代码可以随时破坏它们。