今天是「两个架构的虚拟化同时往前推」：arm64 的 GCS（Guarded Control Stack）到第 21 版 —— 把硬件保护的返回地址栈交给客户机；另一边 KVM x86 的 APX 到 v8 ， 让客户机也用上扩展通用寄存器。顺带一提，APX 那封信里作者专门预告了 AI 评审工具 Sashiko 的误报。
🎬 今日导读 / section 头条 KVM arm64 GCS 到 v21（15 帖）：硬件保护的返回地址栈，客人也能用
头条 KVM x86 APX 到 v8（20 帖）：客户机拿到 EGPR，作者预告 Sashiko 误报
fs mount 一批修复，标题自称「the Oprah edition」；netfs 用 bio_vec 链替掉 folio_queue 到 v14
Rust Rust PCI SR-IOV 到 v3；转换派生宏 v7 补齐 From 的穷尽性；ID 区间保留 v9
DRM msm DP 静态 HDR 13 帖；nova-core 命令队列 v3；Renesas RZ/G3L 显示子系统 v4
media Dell Latitude 5285 二合一相机 v11（旧机器靠软硬件一起点亮）
mm device DAX 转 section-based vmemmap 到 v6
机制 JHB100 SoC 时钟复位 23 帖；i.MX952 ISI 到 v4（RAW14 与对齐）
📊 板块活跃度 / column 数据截至 10-01 06:23 北京，近 24h 各板块真实计数：net 752 · DRM 354 · media 215 · PCI 187 · mm 160 · Rust 154 · fs 146 · block 42 · arch 31 · LSM 26 · rt 19 · virtio 1。 net 依然是量最大的一头，但今天最重的两条都在 lkml（两个架构的 KVM 虚拟化）， Rust 的 154 也明显高于平常——多为 PCI SR-IOV、派生宏、ID 区间这几条系列在往返。
💡 今日头条 / section 可控返回栈进 KVM：arm64 GCS 的客户机支持到第 21 版 〔10-01 05:48 北京〕· [PATCH v21 00/15] KVM: arm64: Provide guest support for GCS
现状 GCS（Guarded Control Stack）是 arm64 的硬件特性：维护一个受保护的返回地址栈 ， 用于对抗 ROP（返回导向编程）攻击，也方便采集调用栈。它由内存属性保护， 只能通过特定的 GCS 指令写入；BL 执行时把 LR 压进 GCS，RET 时弹出并与 LR 比对， 不一致就报错——而且 GCS 操作只能作用在 GCS 页上。
痛点 硬件强制的返回地址校验，比纯软件的影子栈（如 clang 的实现）更难攻击、开销也更低—— 因为函数出入口不需要额外指令。但虚拟机里的客户机此前拿不到它。
为什么 这条线的价值在「虚拟机里的进程也能被硬件保护 」：把 GCS 的上下文 （GCS 指针、GCS 相关系统寄存器、以及配套的异常处理）纳入 KVM 的 vCPU 状态保存与恢复。 客人用上它之后，跑在 VM 里的应用同样获得 ROP 防护。
下一步 v21 这个版本号本身就是信息 ——能走到第 21 版说明评审在持续收敛而不是卡死， 但也说明这条线的边角之争（系统寄存器建模、迁移兼容、异常语义）格外费时间。
一句话点评 硬件安全特性进虚拟化通常比进裸机慢得多：多一层「客户机的这个状态怎么保存、怎么迁移」要谈。 21 版是个信号——方向没人反对，细节磨得久。
🔗 原文
x86 客户机也能用扩展寄存器：KVM APX 到 v8，作者还预告了 AI 评审的误报 〔10-01 05:37 北京〕· [PATCH v8 00/20] KVM: x86: Enable APX for guests（Chang S. Bae / Intel）
现状 APX（Advanced Performance Extensions）给 x86 增加了 EGPR（扩展通用寄存器）等能力。 KVM 要把这些能力透给客户机，就得在 vCPU 状态保存/恢复、VMX 的指令信息解码、 以及模拟器路径上都接上——20 帖正好覆盖这些面。
方案 v8 是重基到 KVM next 树的一版，并带上了 Zhao 的 test tag。帖子序列从 「扩展 VCPU 寄存器以容纳 EGPRs」开始，走到 VMX 侧保存、XSAVE ABI 的 APX 状态、 指令信息解码重构，最后是模拟器对 EGPR 的支持。
值得单独看的 作者在开头写了一句很实在的话：I expect Sashiko to reply to a bunch of patches. I previously found some false positives, so I will comment on them again in this posting. ——他预先声明哪些 AI 评审的告警是误报。这在投稿信里还是新鲜事： AI 评审工具已经成为作者需要主动应对的「另一方」 。
下一步 v8 阶段，形态已经稳定。看 KVM 维护者对 EGPR 在迁移场景下的处理意见。
一句话点评 功能本身是常规的「新硬件特性透传」，但作者那句预告更有时代感—— 邮件列表上现在同时有人和 AI 在评审。
🔗 原文
📰 fs 文件系统 / column ★ mount 一批修复，作者把标题写成「the Oprah edition」〔09-30 21:32 北京〕· [PATCH 00/17] mount: more bugfixes, the Oprah edition
定位 VFS 挂载层的修复合集。标题致敬美国脱口秀主持人 Oprah 的经典桥段—— 「你有车！你也有车！」——意思是这一轮修复多到见者有份 。
效益 17 帖覆盖挂载路径上的若干边角。内核标题通常克制，这种自嘲式标题属于少数， 读起来能感到作者修到一定数量后的无奈。
和你相关 挂载层的边角修复值得扫一眼，但重点不在这一批——它更多是清理。
🔗 原文
★ netfs 用 bio_vec 数组链替掉 folio_queue，到 v14〔09-30 20:53 北京〕· [PATCH v14 00/10] netfs, iov_iter: Use a chain of bio_vec arrays instead of folio_queue（David Howells）
定位 netfs 是网络文件系统的公共层，iov_iter 是内核搬运数据的通用迭代器。 这项改动把「用 folio_queue 描述待搬数据」换成「用 bio_vec 数组组成的链」。
为什么 bio_vec 是块层描述「一段内存 + 长度」的标准结构，bio 由它组成。 换过去之后，netfs 的数据描述和块层说同一种语言——少一层转换 。
下一步 v14 且作者是 David Howells，属于「长时间打磨、反复重发」的典型。 这类底层数据结构替换不进则以，进了影响面很广。
和你相关 数据搬运路径的表示统一，属于长期收益型重构。
🔗 原文
📰 Rust / column
📰 DRM 显示 / column
📰 media / mm / net / column
📌 机制雷达：2 条跨域大改动 / section 两个架构同时推进虚拟化安全特性 arm64 GCS 与 x86 APX 是两条独立线，但都属「把新的 CPU 能力透给客户机」。 共同难点从来不是特性本身，而是客户机状态的保存、恢复与迁移兼容 —— 这也是它们都要走到两位数版本的原因。 GCS 原文 AI 评审进入作者的工作流 APX 那封信里作者主动预告 Sashiko 的误报。这意味着投稿信现在要同时对着 人类维护者和 AI 评审工具 写——作者得预判机器会挑出什么、并提前说明哪些不算问题。 这个变化值得持续观察。 原文
📖 本期概念速查 / section GCS（Guarded Control Stack） arm64 的硬件保护返回地址栈。受内存属性保护、只能由特定 GCS 指令写入； BL 压栈、RET 弹出比对，不一致即报错。用于对抗 ROP 攻击。
APX / EGPR APX（Advanced Performance Extensions）是 x86 的指令集扩展， EGPR（Extended General Purpose Registers）是它带来的扩展通用寄存器。KVM 要把它们透给客户机。
Sashiko 内核社区的 AI 代码评审工具，会针对补丁自动回帖。作者们开始需要在投稿信里 预先说明它的哪些告警是误报。
bio_vec 块层描述「一段内存 + 长度」的结构，若干 bio_vec 组成一个 bio。 netfs 这轮改动用它替换 folio_queue，让数据描述与块层对齐。
v21 / v14 / v11 内核补丁的版本号是「重发次数」。两位数通常意味着：方向被接受， 但边角问题（兼容性、迁移、边界语义）反复打磨了很多轮。
如果对你有用，点个赞，或留言聊聊你最关心的板块。
数据来源：lore.kernel.org（全内核 13 列表）· 北京时间
