Hola:
Ayer en la clase de consulta me preguntaron esto y yo quedé en contestar. A ver si ahora logro explicarlo. Cuando usamos virtualización terminamos teniendo un sistema operativo virtualizado, el objetivo del hipervisor es engañar al SO para que ejecute en hardware virtual. Hasta ahí es claro.
Ahora, cuando el SO quiere iniciar un proceso virtual lo que hace es crear su PCB, las tablas de páginas del proceso en memoria e intenta configurar la MMU para que apunte a la memoria donde están esas tablas. Pero el hipervisor no puede dejar que pase esto porque esas tablas de páginas apuntan a memoria física virtualizada (memoria física que existe solo dentro de la máquina virtual). Por suerte, configurar la MMU es una operación protegida, entonces cuando el SO intenta hacerlo, salta una excepción/interrupción que es atrapada por el hipervisor. Ahí el hipervisor entra en juego, traduce las direcciones físicas virtuales a direcciones físicas reales, configura la MMU con esas nuevas direcciones y mantiene ocultas las tablas de páginas creadas por el SO. Es decir que el SO cree que sus tablas de páginas fueron configuradas con éxito pero en realidad el hipervisor lo engaña y termina configurando otras tablas de página (las shadow page tables) con el mapeo a la memoria física real. Todo esto se hace para que el SO no "vea" la memoria física real.
El problema aparece cuando el SO quiere modificar una tabla de página. Como las tablas de página están en memoria del SO (en el PCB del proceso), modificar una de estas tablas es simplemente acceder a memoria y esa no es una operación privilegiada. Por lo tanto el hipervisor no se entera del cambio en las tablas de página y por lo tanto no tiene chance de actualizar el mapeo real que hay en la MMU que es el de las shadow tables.
La forma que tiene el hipervisor de forzar esa excepción cuando el SO escribe en su tabla de páginas es hacer readonly la porción de memoria de las tablas de página y santo remedio.
Espero que se haya entendido.
Saludos,
Santiago.