Making Xen's dom0 I/O path NUMA aware
2 days ago
- Dom0的内存布局存在偏差，因为Xen的E820修剪策略优先从最低地址节点分配；通过按比例修剪，将内存均匀分布到所有宿主机NUMA节点已修复此问题。
- 现在在特定条件（PVH、vCPU固定、vCPU/pCPU数量相等、多节点）下，会为Dom0合成三块NUMA拓扑结构（SRAT、SLIT、x2APIC ID），使Dom0完全支持NUMA感知。
- 实现过程中发现的缺陷包括：使用内部Xen ID而非宿主机邻近域进行节点编号、SRAT内存范围切分错误，以及在子NUMA硬件上的按比例修剪问题。
- 新的超级调用（XENMEM_get_mfn_pxms）将外部内存页的宿主机邻近域暴露给Dom0，支持按节点内存池管理，并使后端驱动能感知环的NUMA节点。
- 后端驱动（blkback、netback）现在将内核线程、中断和事件通道绑定到环的宿主机节点，修复了irqbalance覆盖中断亲和性及卸载时WARN消息的问题。
- 前端驱动（blkfront、netfront）通过显式节点轮转将多队列环分布到客户机节点，并在netfront中增加XPS控制，确保发送路径保持NUMA本地性。
- 整个半虚拟化I/O路径（客户机→环→后端→物理设备）现实现NUMA本地化，除共享物理网卡时保留一次跨互连访问。
- 网卡/HBA中断的设备局部性现在生效，因为Dom0能获取真实拓扑，支持正确的中断分配与控制导向。
- 发现工具栈中存在vNUMA内存布局的潜在缺陷（虚拟节点索引被用作物理节点ID）；该问题仅在非连续布局的内存带宽基准测试中才显现。
- 代码已在Edera的Xen分支和Linux内核补丁中可用，工具栈特有的编排机制（放置启发式算法）暂未包含。