在内核模块中实现 CPU 扩展答案

【问题标题】：Implement CPU extensions in a kernel module在内核模块中实现 CPU 扩展
【发布时间】：2010-08-05 23:24:54
【问题描述】：

我正在寻找有关在内核模块中实现某些 CPU 扩展的信息。我发现了一些相关的东西：http://www.mirrors.docunext.com/lxr/http/source/arch/mips/kernel/unaligned.c 事实上，这是我能找到的唯一一个更接近的源代码。

基本上，我有一个使用某些 CPU 扩展构建的仅二进制共享对象，我需要在具有大部分指令集但不是花哨的新东西的稍旧的 CPU 上运行它。是的，我知道这会很慢，但总比使用 SIGILL 崩溃要好。

【问题讨论】：

我认为您的问题可能有点过于宽泛。您已经有了基本想法 - 拦截最终导致 SIGILL 的陷阱，而是检查用户进程状态并模拟它尝试执行的指令。（我认为你不能从一个模块中做到这一点 - 它可能必须被编译，除非你为模块添加一些垫片以连接到）。那么真正的问题是什么？
我希望有人有做这样的事情的经验，或者如果我遗漏了什么，至少可以为我指出正确的方向。内核本身有与 FP 芯片仿真相关的片段，以及上面的链接。编写 shim/framework 似乎是实现最大可重用性/可扩展性的下一步。基本上，我正在寻找 SIGILL 的来源，然后从那里开始。有什么更有效的吗？或者，有人知道哪里是诱捕的好地方，即文件 x 行 y？抱歉有很多问题，我不想开始太多新线程。

标签： linux linux-kernel kernel kernel-module kernel-extension

【解决方案1】：

我认为你可以在用户空间中做到这一点。使用sigaction() 为SIGILL 安装处理程序并指定SA_SIGINFO。 siginfo_t 中的字段si_code 允许区分SIGILL 的几个原因。例如，当信号来自kill() 时试图模拟一条指令是没有意义的。处理程序的第三个参数指向一个包含故障时 CPU 上下文的结构（参见文档）。您可以修改它并从信号处理程序返回，更改生效；如果这不起作用，请尝试setcontext()。

显然，它的效率会比在内核中执行的要低一些，但更干净、更安全。

【讨论】：

【解决方案2】：

你可以这样做，但它有点痛苦。无效操作码需要拦截，要么修改现有的非法指令处理程序，要么包装处理程序，脏又复杂。

如果您想避免任何内核模块，而是作为纯内核执行，则包装异常方法可能是唯一的方法。如果能修改内核，打补丁的handler就更好了。

【讨论】：

【解决方案3】：

我认为您无法使用内核模块解决此问题。我认为您要么需要在允许缺少指令的 VM 中运行它（我会尝试使用 XEN），要么需要重新编译对象以使其不使用它们。

【讨论】：

我认为@joe 的意思类似于在没有 FP 单元的旧处理器上使用的旧 FP 仿真技巧。我不确定现在是否有人对此进行研究。
外部FP单元实际上是大图的第二部分。但是当我谈到它时，我会搞砸的。这是一个 x86 示例（目标 CPU 是 ARM）：如果 CPU 不支持 SSE2，当它遇到 ADDPD 指令时，内核将抛出（或其他类似过滤器的东西，以更快者为准）内部 SIGILL自己捕获（内核模块等），然后调用实现 ADDPD 的特定函数。它不一定是内核模块，可能必须为此编写内核框架，这很好。

【解决方案4】：

好吧，在阅读了内核源代码之后，似乎已经有少量支持了。我真的看不出它实际使用了多少，但是存在一个链表来存储各种模拟指令。如果我能够真正做到这一点，我可能会将其更改为内核头提供的树。

如果我对内核模块的理解正确，那么支持可插拔仿真似乎不会有问题。

【讨论】：