问题标签 [fxsave]

有一个令人讨厌的问题暂时难住了我公司的一些工程师试图对其进行调试。

C++ 程序通常在具有 MPI 的多核计算机集群上运行。

它会运行很长时间——也许是几天——然后突然失败。

大多数从事它的工程师已经消除了程序本身存在错误的任何合理可能性，因此他们开始将责任归咎于可能的硬件问题，但我怀疑 Linux 内核模块或设备中一定存在软件问题司机。

值得怀疑的是，内核模块或设备驱动程序为了进行一些浮点计算，正在以在 SMP 系统上不安全的方式执行 FXSAVE/FXRSTOR。它可以像对需要可重入的内核例程中的静态缓冲区执行 FXSAVE 一样简单。这将创建一个竞争条件错误，该错误很少会破坏线程的浮点上下文。

在应用程序级别，似乎正在发生的事情是 MXCSR 的一个或多个位（它是 FXSAVE/FXRSTOR 上下文的一部分）突然更改，但没有应用程序代码来更改它。

多年前我在 Windows 上遇到过类似的情况，最终证明是视频驱动程序中的一个错误，因此当应用程序代码被操作系统抢占时，该线程上下文中的一些 MXCSR 位被破坏。

我不是 Linux 内核黑客或设备驱动程序开发方面的专家，但我了解到重入规则已经发生了很大变化；在非 SMP 和 SMP（多核）系统之间；内核版本之间；等等因此出现竞争条件错误的可能性似乎是合理的。

所以我的问题是：是否有任何已知的 Linux 驱动程序（或内核）错误符合该描述？

如果他们有类似的症状，我可以引用的任何先例都会有所帮助。在这一点上，很多相关人员（恕我直言）浪费时间思考“好吧，我的代码中没有错误，所以它一定是坏硬件。” 我想让他们超越这一点，并寻找更有可能成为真正原因的东西。

这与 这个问题有关。

我不是 Linux 设备驱动程序或内核模块方面的专家，但我一直在阅读 Rubini & Corbet 的“Linux 设备驱动程序”[O'Reilly] 和一些在线资源，但我一直无法找到关于这个具体问题的任何事情。

何时允许内核或驱动程序模块使用浮点寄存器？
如果是这样，谁负责保存和恢复其内容？
（假设 x86-64 架构）

如果我理解正确，每当 KM 运行时，它都在使用已从某个应用程序线程抢占的硬件上下文（或硬件线程或寄存器集——无论您想调用什么）。如果您在 c 中编写 KM，编译器将正确确保通用寄存器正确保存和恢复（就像在应用程序中一样），但浮点寄存器不会自动发生这种情况。就此而言，许多 KM 甚至不能假设处理器具有任何浮点能力。

我猜想使用浮点的KM必须小心保存和恢复浮点状态是否正确？是否有这样做的标准内核函数？

是否在任何地方都说明了此编码约定？
对于非 SMP 驱动程序，它们是否不同？
对于较旧的非抢占式内核和较新的抢占式内核，它们是否不同？

什么时候可以调用xsavesand xsaves64？

使用英特尔软件开发模拟器（8.12.0-2017-10-23），我可以毫无问题地xsaves64 + xrstors64从用户空间使用，但尝试使用xsaves + xrstors会产生：

这同样适用于xsavec，它产生：

64 位模式的非_64变体xsave_和不允许使用吗？xrstor_