私は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
一ヶ月間二回目の事故だ。
ここでシステムプログラミングに関する質問をたくさん見てここに投稿するようになりました。
答え1
XenはRAMへの直接アクセスを提供しませんが、Xenの監督の下で、物理ボリュームがページテーブルの更新に物理RAMを使用できるようにします。