今天两条都关于「别再每次都做全量工作」：KVM 的嵌套 SVM 以前每进出一层就刷掉整个 TLB， 现在给 L2 单独分配 ASID；s390 则是在惰性 MMU 模式下批量化 PTE 更新， 不再一条一条写。另一条值得看的是 Hyper-V vmbus——让 ring 与主机可见缓冲跨重启存活， 为的是 guest 热更新。
🎬 今日导读
/ section 头条 KVM nSVM 29 帖：给 L2 单独 ASID，不再每次嵌套切换全量刷 TLB
头条 s390/mm 15 帖：惰性 MMU 模式下批量更新 PTE
net Hyper-V vmbus 14 帖：让 ring 与主机可见缓冲跨内核热更新存活
media dma-buf 经 io_uring 读写到 v9：一天内从 v8 走到 v9
fs Landlock 管到 namespace 与 capability（v5，8 帖）；netfs 抽出 bvecq chain position（v14）
DRM Panfrost 大修到 v13：perfcnt、runtime PM、重构
PCI RZ/G3S PCIe 热插拔到 v6；xfs/nfsd 一次映射整个 pNFS block layout
机制 v7.4 合入窗口前的准备系列集中出现（RCU、rcutorture、DCD）
📊 板块活跃度
/ column 
数据截至 10-08 06:23 北京，近 24h 各板块真实计数：net 468 · DRM 203 · media 183 · mm 103 · PCI 87 · fs 70 · block 41 · LSM 31 · Rust 27 · arch 13 · rt 8 · virtio 0。 net 依旧是量最大的一头（多为驱动修复流）；今天的重量集中在 lkml 与 mm 两条—— nSVM 的 29 帖与 RCU 系列属前者，s390 的批量 PTE 属后者。
💡 今日头条
/ section 嵌套虚拟化不必每次刷掉整个 TLB：nSVM 给 L2 单独分配 ASID
〔10-08 08:14 北京〕· [PATCH v2 00/29] KVM: nSVM: Optimize nSVM TLB flushes
现状 AMD 的嵌套虚拟化（nSVM）里，L1 是宿主、L2 是跑在 L1 里的客户机。 此前 L2 和 L1 共用同一个 ASID——ASID 是 CPU 用来区分不同地址空间的标记， TLB 条目挂在它上面。共用就意味着：每次 L1↔L2 切换都得把 TLB 刷干净， 因为不然无法区分哪些条目属于谁。
痛点 嵌套切换在这种负载下非常频繁，全量刷新等于每切一次就把积累的地址翻译全部丢掉， 切回来再重建。成本随嵌套层数线性放大，这是嵌套虚拟化性能长期的一个痛点。
方案 29 帖做两件事：一是给每个 vCPU 的 L2 维护独立的 ASID，切进切出只失效属于对方的那些条目， 而不是整表刷新；二是取消动态 ASID 分配，改为每 vCPU 静态分配（启用嵌套时用两个）。 作者给出的依据很直接：现代 CPU（Rome / Milan / Genoa / Turin）宣称支持 32K 个 ASID， 动态分配那套复用机制已经没有存在必要。
为什么 路线选择的本质是向 VMX 看齐——Intel 侧早就用 VPID 给 L2 单独标识， nSVM 这轮是把 AMD 侧补到同一个模型上。取消动态分配同样是简化： 既然 ASID 空间够大，就不用再维护一套分配/回收逻辑。
效益 嵌套场景下 TLB 失效的范围从「整表」缩小到「属于某一层的那部分」， 地址翻译的复用率提高。对跑多层虚拟化的云平台是直接的性能收益。
下一步 v2 阶段，且作者明确标注了测试覆盖的边界：新增 selftest 覆盖 L1 为 L2 刷 TLB、 以及 KVM 同时为 L1 和 L2 触发刷新的场景；但 Hyper-V 相关部分只做了编译测试， SEV 部分只用 SEV selftest 验证过。这种坦白对评审很有用——它指出哪里还需要人肉把关。
一句话点评 「硬件能力够了，旧机制就该退休」的典型。取消动态 ASID 分配比新增独立 ASID 更能说明这个系列的性质： 它做的是减负，不是加功能。
🔗 原文
s390 在惰性 MMU 模式下批量改 PTE
〔10-07 19:43 北京〕· [PATCH v8 00/15] s390/mm: Batch PTE updates in lazy MMU mode（Alexander Gordeev / IBM）
现状 「惰性 MMU 模式」是 s390 上的一种加速开关：在这种模式下，页表更新不是立刻生效， 而是先攒起来、稍后一次性提交。它牺牲一部分语义的即时性，换取更少的机器开销。
痛点 但即便进了惰性模式，PTE 仍然是逐条更新的——批量提交的好处没能吃满。 更新的条数一多，逐条写的开销就回来了。
方案 v8 共 15 帖，把 PTE 更新在惰性 MMU 模式下改成批量处理： 一批页表项一起构造、一起提交，而不是一条一条走完整流程。
下一步 已到 v8，属于长期打磨的架构专属优化。看 s390 维护者对批量边界的意见—— 批量越大收益越高，但中间态的一致性要求也越紧。
🔗 原文
📰 net / 虚拟化
/ column ★ Hyper-V vmbus：让 ring 与主机可见缓冲跨内核热更新存活
〔10-08 03:08 北京〕· [PATCH v2 0/14] hv: vmbus: make rings and host-visible buffers survive boot
定位 vmbus 是 Hyper-V 虚拟机的虚拟总线。ring 是 guest 与主机之间传递消息的环形缓冲， 「主机可见缓冲」则是双方共享的内存区——这两块都是设备状态的核心。
做法 14 帖让这些缓冲区跨重启存活。放在内核热更新（live update）的大背景下看就清楚了： 新内核接管时，如果 vmbus 的 ring 和共享缓冲还在原位，虚拟机就不必重新枚举虚拟设备。
下一步 v2 阶段。这条线与本周反复出现的 KHO/LUO 热更新系列是同一条长线， 区别只是它在 Hyper-V 这一侧。
和你相关 内核热更新正在从「内存、设备、vCPU」一路铺到各虚拟化平台的具体总线上。 vmbus 这轮是 Hyper-V 侧的适配。
🔗 原文
📰 fs 文件系统
/ column
📰 其余板块
/ column
📌 机制雷达：v7.4 合入窗口前的准备系列
/ section RCU 系列集中出现 同一天里 RCU 相关至少两批：atomic SRCU（21 帖）与 Miscellaneous RCU updates for v7.4（10 帖）， 另有 rcutorture 的 torture-test updates（8 帖）。标题里带「for v7.4」意味着这是面向下一个合入窗口的 预定动作——RCU 的更新习惯以固定节奏成批进入。 原文 DCD Prep Series 到 v15 「DCD」（Detached Control Device 相关）的准备系列已到第 15 版。 带 Prep 字样的系列通常是为某个更大改动先做铺垫，本身不含功能，但决定后续能否顺利落地。 原文
📖 本期概念速查
/ section ASID（Address Space ID） CPU 用来区分不同地址空间的标记，TLB 条目挂在它上面。不同 ASID 的翻译可以共存于 TLB， 切换地址空间时不必全表刷新——本期 nSVM 的核心就是给 L2 单独分配 ASID。
nSVM / nested SVM AMD 的嵌套虚拟化：L1 是宿主，L2 是跑在 L1 里的客户机。KVM 要同时处理两层地址翻译。
惰性 MMU 模式（lazy MMU） s390 上的加速开关：页表更新不立刻生效，先攒起来稍后一次性提交，用语义即时性换机器开销。
vmbus / ring vmbus 是 Hyper-V 虚拟机的虚拟总线；ring 是 guest 与主机之间的环形消息缓冲。 本期系列让它们跨内核热更新存活，避免重新枚举虚拟设备。
bvecq chain position netfs 里描述「数据在 bio_vec 链上的哪个位置」的抽象。上一轮把 folio_queue 换成 bio_vec 链之后， 这轮把位置表示也抽出来。
如果对你有用，点个赞，或留言聊聊你最关心的板块。
数据来源：lore.kernel.org（全内核 13 列表）· 北京时间