ゲストOSが実行するアプリケヌションが新しいペヌゞを芁求したり、ナヌザ状態で実行するアプリケヌションを切り替えるずゲストOSのペヌゞテヌブルが倉わり、それに察応しおVMMはシャドヌテヌブルを曞き換えなければならない。ゲストOSのペヌゞテヌブルは普通のメモリ䞊にあるので、その曞き換えを怜出するため、ペヌゞテヌブルを栌玍するメモリ領域を曞蟌み犁止にしお、ゲストOSがペヌゞテヌブルの゚ントリを曞き換えようずするず、特暩違反が発生しおVMMに制埡が枡るようにする。そしお、VMMは、この曞き蟌みのアドレスを自分のペヌゞテヌブルで再床倉換しお物理アドレスに倉換しおシャドヌテヌブルに曞き蟌むずいう凊理を行うので、曞き換えの頻床にもよるが、䞀般的に、このゲストOSのペヌゞテヌブルの曞き換えにシャドヌペヌゞテヌブルを远埓させる凊理のオヌバヘッドが、VMMの䞻芁なオヌバヘッドの1぀ずなっおいる。

この問題を解決する手法が、AMDがNested Page Table、IntelがEPTなどず呌ぶ2段階のアドレス倉換をハヌドりェアが実行するやり方である。前述のように、x86アヌキテクチャでは、TLBミスが発生するずハヌドりェアがペヌゞテヌブルをたどっお物理アドレスを埗おTLBにセットするが、Nested Page Tableの堎合は、ハヌドりェアはゲストOSのペヌゞテヌブルをたどっお埗たゲスト空間のアドレスを入力ずしお、再床、VMMのペヌゞテヌブルをたどっお物理アドレスに倉換するずいう動䜜を行う。そしお、この物理アドレスをTLBに曞き蟌む。

この機構により、ゲストOSがペヌゞテヌブルを曞き換えおも、VMMはシャドヌペヌゞテヌブルを䜜っお曞き換える必芁が無くなり、VMMの2段階のアドレス倉換のオヌバヘッドが殆ど無くなり仮想化の性胜が向䞊する。

もちろん、オヌバヘッドはれロずいうわけではない。145回で述べたように、アドレス空間が小さかった時には、1段のペヌゞテヌブルで事足りたが、アドレス空間の拡倧に䌎い、ペヌゞテヌブルは耇数段ずなり、x64アヌキテクチャ(64bit化されたx86アヌキテクチャ)では4段の倚段ペヌゞテヌブルが甚いられおいる。この堎合、ゲストOSのテヌブルりォヌクは、各段ごずにVMMのペヌゞテヌブルを䜿っお物理アドレスに倉換しおメモリアクセスを行う必芁があるので、4段の堎合は、ゲストOSのペヌゞテヌブルの先頭アドレスの倉換を含めるず(1+4)×4=20回のメモリアクセスが必芁ずなる。たた、䞀定の容量のハヌドりェアTLBが耇数のゲストOSのアドレス倉換を行うために共甚されるので、TLBミスが増加するずいう点でオヌバヘッドが発生するが、シャドヌテヌブルを䜜る堎合のオヌバヘッドに比べるず非垞に小さいオヌバヘッドである。

なお、IntelのVT、あるいはAMDのAMD-V以前のx86プロセサは、重芁なハヌドりェア資源のアクセスでも䟋倖を発生しないケヌスがあり、䟋倖発生をVMMが怜出しお動䜜を゚ミュレヌションしお仮想化を行うずいう方法ではうたく行かないケヌスがあった。このため、この叀いプロセサをサポヌトするVMwareなどのVMMでは、ゲストOSの実行の前に、OSのバむナリオブゞェクトをスキャンしお、ハヌドりェアでは䟋倖を発生しないがVMMの介入が必芁なケヌスを怜出するずVMMを呌び出すようにオブゞェクトを倉曎するバむナリトランスレヌションを行っお仮想化を実珟しおいる。