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 內核中及時完成，但至少這項改進正在進行中。