충돌 분석 및 레벨 4 페이지 테이블

저는 256Gb RAM 및 96 코어 CPU를 갖춘 호스트에서 15개의 가상 머신(pv+hvm)을 실행하는 xen 3.4.2를 실행하고 있습니다.

하지만 최근에 내 호스트가 디버그 로그에서 충돌했습니다.

translating ffff83183fcb0000 with CR3 100ae42000 and 4 levels of page table.

비슷한 줄이 너무 많아서

cannot translate address 0 < ffff830000000000 without cr3

Xen PV에 대한 나의 이해에 따르면,

하이퍼바이저를 사용하면 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

한달새 두 번째 사고다.

여기서 시스템 프로그래밍과 관련된 질문을 많이 봐서 여기에 게시하게 되었습니다.