Discusión sobre GUEST OS Clock (TIMEKEEP) en Máquina Virtual

La descripción del concepto de sincronización de reloj en el sistema operativo tradicional

Sabemos que hay muchos relojes en el hardware del sistema, como RTC /PIT /HPET /ACPI PM TIMER /TSC, que se caracterizan por sus características. Puede dividirse en dos categorías: relojes periódicos en forma de interrupciones, como RTC /PIT /HPET, etc., y el otro es un reloj incremental de un paso, como TSC, que existe en el contador CONTADOR. La diferencia entre ellos es que el reloj periódico se logra mediante la transmisión periódica de interrupciones, como la frecuencia de los latidos del corazón. El reloj incremental de un solo paso no envía una interrupción, pero el software necesita leer activamente su registro de CONTADOR para obtener la hora.
Por lo tanto, el sistema operativo utilizará selectivamente el reloj periódico como la fuente del reloj para la hora normal, y usará el reloj incremental de un solo paso para la calibración de la hora o las estadísticas de rendimiento. Esto es cierto para el sistema de ventanas del sistema Linux.
La sincronización de reloj a la que nos referimos aquí es que el reloj periódico en el sistema debe estar sincronizado con el reloj incremental de un solo paso, por ejemplo. Si el sistema operativo utiliza el reloj RTC como la fuente de reloj periódica de TIMEKEEP, y la frecuencia es de 100 HZ, la frecuencia de la CPU del sistema es de 3000MH y la frecuencia del TSC es igual a la frecuencia de la CPU, entonces se debe generar cada interrupción de RTC (la hora del sistema avanza 1/100 de segundo). El CONTADOR TSC también debe incrementarse en 1/100 * 3000M. Si la relación anterior es estable, entonces llamamos al reloj del sistema sincronizado.
Entonces, ¿por qué necesita la sincronización de TSC y RTC? El proceso TIMEKEEP del sistema operativo a menudo (al menos el sistema Linux lo hará, pero la ventana puede no) utilizará el tiempo de TSC para corregir el tiempo de mantenimiento de RTC (en los jiffies de Linux), porque la interrupción periódica de RTC puede ser accidental Perdida (por ejemplo, máscara de interrupción, etc.), y el contador del TSC se ejecutará de manera estable sin perder tiempo, por lo que la temporización del sistema mantenida por el RTC se retrasará respecto a la del TSC, por lo que es necesario calibrar constantemente la temporización del RTC, es decir, dejarlo El tiempo de TSC es consistente.
(Para la acción de calibración específica, vea la función timer_tsc señalada por cur_timer en timer_interrupt
en el sistema Linux).

Sistema operativo en el entorno tradicional, ya sea que TSC o RTC sean responsables de la operación del hardware, siempre que el hardware sea estable, entonces TSC y RTC, aunque se ejecuten de forma independiente, deben estar sincronizados. . Por lo tanto, el problema de sincronización no es un problema en el entorno tradicional.

Sincronización entre relojes analógicos en una máquina virtual
Si la sincronización del reloj no es un problema en un entorno tradicional, ¿cuál es el problema con la sincronización del reloj en un entorno virtual?
¡Las condiciones generadas por el reloj en el entorno virtual y el entorno tradicional han cambiado! Los relojes periódicos como RTC no son generados por el hardware correspondiente, sino que son simulados por los temporizadores de software (consulte el artículo anterior), pero la adquisición del TSC no pasa la simulación, o el registro CONTADOR TSC del hardware para obtener el valor del TSC (solo Por lo tanto, no hay simulación porque no podemos simular un CONTADOR TSC estable de un solo paso a través del software, y es más simple y más razonable leer el TSC del hardware directamente. Ya sabemos que en un entorno virtual, las interrupciones periódicas del reloj, como la emulación de software RTC, no pueden activarse con precisión y enviarse a GOS (habrá demora en el entorno virtual y el intervalo de activación es inestable), y la sincronización de RTC y la hora de TSC no están sincronizadas (TSC Corre rapido). En el sistema Linux, la salida imprime mucha información "¡Perdiendo demasiados tics!" (El código correspondiente está en timer_tsc
).

Para los sistemas Linux que requieren TSC para corregir la sincronización periódica del reloj, debemos encontrar formas de sincronizar TSC y RTC. De hecho, se nos ha proporcionado el procesador de tecnología virtual de Intel y amd. Cuando el GOS lee el TSC (el sistema x86 tiene una instrucción especial rdtsc), el resultado es un cambio en el resultado original (hardware TSC COUNTER). La suma de los valores de desplazamiento configurables tsc_offset, por lo que podemos configurar el valor de tsc_offset para sincronizar el tiempo del TSC visto por el GOS con su mantenimiento de RTC. El método específico es establecer un nuevo tsc_offset según el tiempo de la sincronización GOS (mantenimiento de RTC) en cada tiempo de inyección de interrupción de reloj (la declaración hvm_set_guest_time en pt_intr_post en vpt.c en xen (pt- > vcpu, pt- (> last_plt_gtime) es completar el trabajo), asegurando así la sincronización del reloj en el entorno virtual.

Sincronización en entornos SMP
La sincronización mencionada anteriormente es para sistemas de un solo núcleo. Para la sincronización de entornos SMP de múltiples núcleos, además de los requisitos anteriores, se requieren múltiples núcleos y tiempo. Sincronización: los TSC en cada núcleo deben estar sincronizados (cada núcleo tiene su propio TSC), y el TSC y los relojes periódicos del sistema deben estar sincronizados.
La sincronización multinúcleo en entornos virtuales tiene muchas dificultades. Es necesario sincronizar completamente la programación síncrona del núcleo (programada o llamada simultáneamente). De lo contrario, es posible enviar una interrupción periódica del reloj a un núcleo. Al ser llamado, obviamente, la interrupción del reloj se perderá y la hora del sistema estará atrasada. En lo que respecta al código Xen, en la actualidad, para mejorar el rendimiento de todo el sistema, cada núcleo está programado de forma independiente, por lo que la posibilidad de la interrupción perdida mencionada anteriormente se almacena.
Para este xen, el reloj periódico está vinculado al núcleo BSP. Debido a que el núcleo AP no recibe la interrupción del reloj, el núcleo Ap no realiza la operación de cronometraje (la temporización se realiza después de que se recibe la interrupción del reloj), por lo que la operación de temporización del sistema y el tiempo de corrección no se realizará, y no se informará de ningún error. "Perder demasiados tictacs ! ", aunque el TSC en el núcleo AP no está sincronizado con la temporización RTC. Sin embargo, el doble núcleo virtual no puede garantizar la sincronización del TSC de los dos núcleos, lo que afectará el funcionamiento normal de muchas herramientas de prueba de rendimiento, ya que muchas herramientas de prueba de rendimiento (pcmark, winsat, etc.) utilizarán el TSC para la medición del rendimiento, por lo que es probable Se encontrará que estos ataques son bajos o inutilizables en el doble núcleo virtual. Este problema no se ha resuelto o no se toma en serio por xen.
Si desea resolver completamente el problema del reloj multinúcleo, debe realizar una gran cantidad de trabajo auxiliar, como activar la interrupción del ipi para notificar a otros núcleos que realicen el procesamiento de sincronización correspondiente cuando se interrumpe el reloj periódico; una vez que el núcleo está programado para ser enviado, los otros núcleos son TSC. También debe congelarse y así sucesivamente.

Resumen:
El problema del reloj en el entorno virtual tiene muchos lugares para estudiar y mejorar. Tenemos una discusión preliminar sobre la compensación y sincronización del reloj en nuestros dos artículos. La implementación de relojes virtuales es un punto tecnológico importante en la tecnología de virtualización, que tendrá un gran impacto en el rendimiento general y la estabilidad del sistema. El código xen actual todavía tiene muchas vulnerabilidades en la virtualización del reloj y espera que los lectores interesados ​​puedan continuar estudiando.