我在具有 256 Gb RAM 和 96 核 CPU 的主机上运行 xen 3.4.2,并运行 15 个虚拟机 (pv+hvm)。
但最近我的主机在调试日志中崩溃了
translating ffff83183fcb0000 with CR3 100ae42000 and 4 levels of page table.
在出现了这么多类似的台词之后
cannot translate address 0 < ffff830000000000 without cr3
根据我对 xen pv 的理解,
hypervisor 使 pv 能够直接访问物理 RAM
但虚拟机管理程序会交叉检查所有对物理内存的调用,而不是使用影子页面。
因此,它在虚拟内存到物理转换方面的开销较小,因为它了解实际映射。
但如果是 HVM 管理程序,则需要将客户机内存转换为物理 RAM。
那么谁能从上面的翻译中向我解释一下,它是针对 hvm ram 翻译管理程序正在做的,还是也会在 pv 中发生?
并在 crash.log 上显示
(XEN) grant_table.c:1408:d0 dest domain 452 dying
(XEN) p2m_pod_cache_get: Breaking up superpage.
(XEN) mm.c:741:d421 Non-privileged (421) attempt to map I/O space 00000000
(XEN) mm.c:741:d421 Non-privileged (421) attempt to map I/O space 000000f0
(XEN) mm.c:741:d352 Non-privileged (352) attempt to map I/O space 00000000
(XEN) mm.c:741:d352 Non-privileged (352) attempt to map I/O space 000000f0
(XEN) mm.c:741:d249 Non-privileged (249) attempt to map I/O space 00000000
(XEN) mm.c:741:d249 Non-privileged (249) attempt to map I/O space 000000f0
(XEN) grant_table.c:1408:d0 dest domain 450 dying
这是一个月内的第二次事故。
我在这里看到了许多与系统编程相关的问题,这就是我将其发布在这里的原因。
答案1
Xen 不提供对 RAM 的直接访问,而是允许物理卷在 Xen 的监督下使用物理 RAM 进行页表更新。