崩溃分析及4级页表

崩溃分析及4级页表

我在具有 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 进行页表更新。

相关内容