英特尔工程师正全力提升x86_64 CPU微代码在Linux下的更新体验,特别关注英特尔系统在Linux上的后期微代码加载,主要服务对象为英特尔的服务器/企业用户。
在Linux内核的x86微代码处理方面,tip.git的x86/microcode分支已经初步改进。这些补丁剔除了多余的互斥操作,去除了过时的调试代码,使得在基于x86的系统上,CPU微代码加载支持不再是可选,而是始终启用的。在英特尔和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内核版本中完成,但至少该改进正在积极进行中。
请访问以下链接以获取更多购买信息:
英特尔旗舰店
作品采用:
《
署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)
》许可协议授权