Linuxeden开源社区英特尔工程师正在努力增强 x86_64 CPU 微代码在 Linux 下的更新体验，尤其是这项工作的最终目标是更好地支持英特尔系统在 Linux 上的后期微代码加载，主要关注点是英特尔服务器/企业用户。
tip.git 的 x86/microcode 分支对 Linux 内核的 x86 微代码处理进行了初步改进。这些补丁删除了一些无用的互斥，丢弃了一些旧的调试代码，并使 CPU 微代码加载支持在基于 x86 的系统上不再是一个选项，而是始终启用。在英特尔和 AMD系统上，任何需要微码加载支持的”合理配置”，现在都会启用该选项。
早先的 x86 微代码加载改进至少已在 TIP 中排队等候，很可能成为即将到来的 Linux 6.6 周期的一部分：
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/microcode
英特尔至强 Max 服务器 CPU
Thomas Gleixner 一直在领导改进英特尔 Linux 系统后期微码加载的工作。他在这个补丁系列中解释说：
“企业用户希望延迟加载微代码。延迟加载是有问题的，因为它需要详细了解变更，并分析该变更是否修改了内核已经在使用的内容。大型企业客户拥有工程团队和深入的技术供应商支持。而普通管理员没有这样的资源，因此内核在后期加载后总是会有污点。
英特尔最近在微码头中添加了一个新的保留字段，其中包含了 CPU 上必须运行的最小微码版本，以确保加载安全。在所有较旧的微代码版本中，该字段的值都是 0，内核会认为这些微代码版本不安全。最小版本检查可通过 Kconfig 或内核命令行执行。这样，内核就会拒绝加载不安全的修订版。默认情况下，内核会像以前一样加载不安全的版本，并玷污内核。如果加载的是安全版本，内核就不会被玷污。
但这并不能解决延迟加载的所有其他已知问题：
– 当前英特尔 CPU 上的延迟加载与启用超线程时的 NMI 相比是不安全的。如果在主处理器加载微代码时发生 NMI，次处理器就会崩溃。
– 当微码更新修改了 MWAIT 时，使用 MWAIT 的软脱机 SMT 姊妹们也会造成损坏。在”nosmt”缓解措施的背景下，这是一种现实的情况。
无论是核心代码还是英特尔特定代码，都根本不会处理这些问题。在尝试实现这一点时，我无意中发现了一些功能失常、复杂得可怕的冗余代码，因此我决定先清理这些代码，以便在干净的石板上添加新功能”。
在 Linux 上，延迟加载微代码是指当系统已经启动并运行软件时，允许更新 CPU 微代码，而不是在 CPU 内核不忙的启动时间提前加载微代码。延迟加载 CPU 微代码对于超大规模企业、云服务提供商和其他大型企业尤其有用，因为它们希望以安全的名义快速部署 CPU 微代码更新，但又要避免系统宕机。目前还不清楚改进后的英特尔 CPU 微代码延迟加载是否能在 v6.6 内核中及时完成，但至少这项改进正在进行中。