Archivo del sitio

[Xen] VT-d (VGA) Passthrough y el rendimiento de las VM en Xen

Luego de que en el nucleo Xen 3.25 de la última versión de GNU/Linux Debian Lenny (5.0.5) se incorporara PCI Back para que las VM pudieran adquirir acceso directo a tarjetas de red, dispositivos PCI y USB, se discutió para la versión 4 (y aprovechando las extensiones paravirt_ops del kernel Linux > 2.6.30) la incorporación de VT-d (VGA) Passthrough, esto es, la posibilidad de incorporar a la VM la capacidad de acceder a la aceleración de video nativa del hardware (video AGP, PCI o PCI-e).

Como el Kernel Xen de Debian Squeeze incopora tanto Xen 4.0 como las opciones paravirt_ops y HVM (Qmeu-KVM extensions for Xen), pues me decidí a probar a ver si en Debian Squeeze y Xen podríamos usar VGA Passthrough para correr máquinas Windows (XP, 2003, 7) y que aprovechen la full-aceleración nativa del video.

Mi Hardware:

Mi portatil es una Lenovo Thinkpad X61 Tablet PC, con 4 Gb de RAM y una tarjeta de video Intel G965 con 256 MB de Video:

lspci -v -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA controller])
Subsystem: Lenovo T61
Flags: bus master, fast devsel, latency 0, IRQ 749
Memory at f8000000 (64-bit, non-prefetchable) [size=1M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915

El Xen de Debian Squeeze trae estas opciones activas:

xm info

host                   : lexotanil

release                : 2.6.32-5-xen-amd64

version                : #1 SMP Sat Jul 24 04:03:11 UTC 2010

machine                : x86_64

nr_cpus                : 2

nr_nodes               : 1

cores_per_socket       : 2

threads_per_core       : 1

cpu_mhz                : 1596

hw_caps                : bfebfbff:20100800:00000000:00000940:0000e3bd:00000000:00000001:00000000

virt_caps              : hvm

total_memory           : 4022

free_memory            : 636

node_to_cpu            : node0:0-1

node_to_memory         : node0:636

node_to_dma32_mem      : node0:636

max_node_id            : 0

xen_major              : 4

xen_minor              : 0

xen_extra              : .1-rc3

xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 

xen_scheduler          : credit

xen_pagesize           : 4096

platform_params        : virt_start=0xffff800000000000

xen_changeset          : unavailable

xen_commandline        : 

cc_compiler            : gcc version 4.4.4 (Debian 4.4.4-5) 

cc_compile_by          : waldi

cc_compile_domain      : debian.org

cc_compile_date        : Wed Jun 30 14:32:51 UTC 2010

xend_config_format     : 4

Entre las capacidades de virtualización completa resalta HVM, por lo que podemos levantar sistemas operativos no-linux (BSD, macOSX, Windows, etc).

¿Qué ganamos con esto?

Imaginen las posibilidades, una máquina con Xen, permite a un usuario correr una VM MS Windows en un entorno “no privilegiado”, sin embargo, el acceso a recursos PCI y VGA le permitirá al usuario acceder como si estuviera en una máquina nativa, con la seguridad de estar encima de un entorno Xen, podemos lograr cosas como:

  • Si a la máquina le cae un virus, eliminamos la máquina virtual y restauramos de alguna copia
  • Podemos jugar de manera full y nativa los juegos de Windows, ya que la aceleración 3D directX encontrará los drivers “oficiales” del hardware.

Por ahora, solo aquellos CPUs que soporten VT-d e iommu podrán ejecutar VGA Passthrough; pero esto representa una ventaja enorme tanto de KVM y de Xen como herramientas de virtualización.

Por ahora, muestro un Windows XP corriendo desde una VM de Xen, mi configuración es:

  • Xen System de GNU/Linux Debian (4.0)
  • Soporte iommu, VT-d y HVM activado
  • Tarjeta de video Intel 965 y CPU Core 2 Duo L7500
  • VM para Xen de Windows XP, con 1Gb de RAM asignado, 64 MB de Video y 2 CPUs en modo compartido (no tengo más!).

Con esta configuración, logré correr la VM en dos combinaciones de resolución:

1024×768 a 32 bits

y 1280×1024 a 16 bits

Hacen falta más pruebas, benchmarks, etc (e instalar programas en la VM) para demostrar el rendimiento de la VM Xen.

Acá un par de pantallazos:

Windows XP corriendo a *casi* full pantalla en una VM Xen, desde un entorno openBox.

El paseo de “Bienvenida”, mostrando las animaciones …

Un MS Windows 2003 Adv. Server corriendo a 1280×1024 dentro de un gnome con compiz!

Futuro

La idea es clara, para aprovechar al máximo el hardware de nuestros equipos, la virtualización es algo necesario y para poder correr cosas como aplicaciones gráficas, juegos y otras aplicaciones de alta demanda gráfica pues VGA Passthrough promete ser la “solución definitiva” para la migración efectiva de todos esos exigentes usuarios.

¿Imaginan tener un equipo de esos Quad-Core, con 3 sistemas operativos en HVM corriendo en paralelo?

Imaginenlo, un MacOS X para el diseñador entusiasta que usa Photoshop, al lado un Windows donde tiene cargado su juego favorito y todo eso sobre el confiable y robusto Linux de siempre.

¡Adiós Excusas de migración! …

Linux Video: mejorando la aceleración de video

Del artículo anterior y de las correcciones a los pequeños bugs del video Intel, descubrí *casí* por accidente la extraordinaria calidad de video que significa usar aceleración y procesamiento de video por hardware.

Como habrán leído en el artículo anterior, se hicieron una serie de cambios en la configuración del video Intel para soportar entre otras cosas:

  • Aceleración nativa UXA
  • 256 MB de video RAM
  • Triple Buffering
  • MTRR y caché de video

La configuración agregada al archivo /usr/share/X11/xorg.conf.d/10-screen.conf es:

Section “Device”
Identifier      “Configured Video Device”
Driver          “intel”
Option          “AllowGLXWithComposite” “true”
Option          “XAANoOffscreenPixmaps” “true”
Option          “AddARGBGLXVisuals”     “True”
Option          “VideoRam”      “262144”
Option          “AccelMethod”    “UXA”
Option          “EXAOptimizeMigration”          “true”
Option          “MigrationHeuristic”            “smart”
Option          “Tiling”                        “true”
Option          “NoDDC”
Option          “BackingStore”  “True”
Option          “AIGLX”  “true”
Option          “MTRR” “on”
Option          “LinearAlloc” “6144”
Option          “MonitorLayout” “CRT,LFP”
Option          “DevicePresence” “true”
Option          “RenderAccel” “true”
Option          “RandRRotation” “on”
Option          “XvMC”          “on”
Option          “TripleBuffer”  “true”
EndSection
Luego de reiniciar el equipo (o al menos las X), reconfiguramos nuestro reproductor de video favorito (al menos mplayer, vlc y xine soportan XvMC).
En mi caso, reconfiguré mplayer para soportar aceleración nativa del video por hardware:

Como verán, hemos seleccionado “gl_nosw” que es aceleración usando openGL y sin software rendering, mplayer enviará el video directamente a la GPU de la tarjeta para su procesamiento, hemos de además habilitar “doble buffering” y “direct Rendering”.

Cuando este lista la configuración, cierran (para que guarde los cambios) y reinician el mplayer.

Para probar la velocidad de reproducción y la “suavidad” de la misma incluso con compiz habilitado, hice un video de demostración.

Hemos ganado además (puesto que usa el plugin vlc) la posibilidad de reproducir videos de youtube (y cualquier flash) a pantalla completa sin “frame drops” (ralentizaciones y pérdida de cuadros).

¡Que disfruten este truco! …

Linux: MTRR allocation failed – mejora de performance del Video Intel

MTRR Significa”Memory Type Range Registers” y es la forma como la memoria RAM es segmentada para ser accedida por distintos dispositivos de hardware (sistema, dispositivos, bus AGP y video-RAM).

El error

En algunos sistemas Linux se presenta un error recurrente (no solamente en Intel, también en ATI) :

dmesg | grep drm
[    7.112889] [drm] Initialized drm 1.1.0 20060810
[    7.938443] [drm] MTRR allocation failed.  Graphics performance may suffer.
[    7.938701] [drm] set up 7M of stolen space
[    8.063932] [drm] initialized overlay support
[    8.705706] fb0: inteldrmfb frame buffer device
[    8.713896] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

Fijense que DRM (Direct Rendering Manager) indica que no pudo registrar un segmento de RAM para la tarjeta de video, advirtiendonos que esto incurría en un serio fallo de performance.

Y muy serio, Sin ninguna corrección, glxgears reporta entre 180 y 200 fps.

Ya yo había hablado de este bug antes y había comentado la forma de corregir el fallo acá.

Solo quería confirmar que en la última versión de Squeeze, el último kernel y la última versión de video-intel el error sigue sucediendo.

Los síntomas

Los síntomas son entre otros (no necesariamente ocurren todos, depende del equipo):

  • glxGears reporta entre 180 y 220 FPS (una velocidad muy baja de frames por segundo)
  • Corrupción y/o lentitud en algunos efectos del compiz
  • Imposibilidad de acceder a video pantalla completa (o videos flash-youtube pantalla completa) de manera “suave”.

Cuando revisamos el estado de los rangos de asignación de la memoria RAM, vemos los siguiente:

cat /proc/mtrr 

reg00: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable
reg01: base=0x13c000000 ( 5056MB), size=   64MB, count=1: uncachable
reg02: base=0x000000000 (    0MB), size= 4096MB, count=1: write-back
reg03: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back
reg04: base=0x0bf700000 ( 3063MB), size=    1MB, count=1: uncachable
reg05: base=0x0bf800000 ( 3064MB), size=    8MB, count=1: uncachable

Vemos que las regiones 04 y 05 (bus AGP y video) están “uncachable”

Fijense que si desactivamos esas regiones y re-activamos (en modo write-back):

echo 'disable=5' >| /proc/mtrr
echo 'disable=4' >| /proc/mtrr
echo 'disable=0' >| /proc/mtrr
echo 'disable=1' >| /proc/mtrr

Ejecutamos:

echo "base=0x0 size=0x80000000 type=write-back" >| /proc/mtrr
echo "base=0x80000000 size=0x10000000 type=write-combining" >| /proc/mtrr

Consultamos:

cat /proc/mtrr

reg00: base=0x400000000 (16384MB), size=16384MB, count=2: write-back
reg01: base=0x200000000 ( 8192MB), size= 8192MB, count=1: write-back
reg02: base=0x000000000 (    0MB), size= 4096MB, count=4: write-back
reg03: base=0x100000000 ( 4096MB), size= 4096MB, count=2: write-back

glxGears mejora un 10%:

glxgears
1494 frames in 5.0 seconds = 298.796 FPS
1582 frames in 5.0 seconds = 316.213 FPS
1616 frames in 5.0 seconds = 323.090 FPS

Pero no vamos a estar ejecutando eso cada vez … así que ejecutaremos la corrección a lo “Debian Squeeze”.

La Solución

Primero, optimizaremos al máximo nuestra tarjeta, para ello crearemos un archivo en:

/usr/share/X11/xorg.conf.d/10-screen.conf

Nota: si es ubuntu-trisquel, la ruta es en /usr/lib/X11/xorg.conf.d/

Al cual agregaremos opciones de “máximo performance” para la tarjeta de video Intel:

Section "Device"
 Identifier      "Configured Video Device"
 Driver          "intel"
 Option          "AllowGLXWithComposite" "true"
 Option          "XAANoOffscreenPixmaps" "true"
 Option          "AddARGBGLXVisuals"     "True"
 Option          "VideoRam"      "262144"
 Option          "AccelMethod"    "UXA"
 Option          "EXAOptimizeMigration"          "true"
 Option          "MigrationHeuristic"            "smart"
 Option          "Tiling"                        "true"
 Option          "NoDDC"
 Option          "BackingStore"  "True"
 Option          "AIGLX"  "true"
 Option          "MTRR" "on"
 Option          "LinearAlloc" "6144"
 Option          "MonitorLayout" "CRT,LFP"
 Option          "DevicePresence" "true"
 Option          "RenderAccel" "true"
 Option          "RandRRotation" "on"
 Option          "XvMC" "true"
 Option          "CacheLines" "1980"
EndSection

Son de vital importancia:

  • VideoRAM: cantidad de RAM que asignaremos al video
  • MTRR: “on” indicarle a la tarjeta de video que hay un rango MTRR para que pueda hacer caché de video
  • AccelMethod: UXA, modo de aceleración 2D/3D nativo de la tarjeta Intel
  • MigrationHeuristic: Descubrí que con “smart” el equilibrio entre 3D y 2D es perfecto, aunque se dedica más a 3D, si queremos favorecer más al 2D, usaremos “always”, si queremos mejorar algunas cosas 3D para compiz usaremos “greedy”.
  • xvMC: Activa la extensión “Video Motion Compensation” de Intel, con lo cual los programas de video (VLC, mplayer, Xine, etc) usarán la GPU Intel (y no software) para procesar el video, mejorando la calidad y el performance.

Posteriormente, editaremos el grub, en la linea de comandos del grub agregaremos:

editamos /etc/default/grub

GRUB_CMDLINE_LINUX="acpi=force vga=0x31B  mtrr_spare_reg_nr=1 enable_mtrr_cleanup"

Las opciones son:

  • enable_mtrr_cleanup: permite al Kernel *eliminar* las regiones y volverlas a crear si ocurre un fallo
  • mtrr_spare_reg_nr: genera una región de *repuesto* adicional en este caso, una sola (región 6) que tomará la tarjeta de video.

Volvemos a generar el menu del grub (grub.cfg)

update-grub2

Y reiniciamos.

Al terminar de reiniciar, podemos ver que DRM inicia correctamente y sin fallos:

dmesg | grep drm
[    5.439814] [drm] Initialized drm 1.1.0 20060810
[    5.729688] [drm] set up 7M of stolen space
[    5.854882] [drm] initialized overlay support
[    6.458946] fb0: inteldrmfb frame buffer device
[    6.462396] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

Que la tarjeta de video logra reservar un espacio “write-combining” en la región 6:

cat /proc/mtrr
reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0bf700000 ( 3063MB), size=    1MB, count=1: uncachable
reg03: base=0x0bf800000 ( 3064MB), size=    8MB, count=1: uncachable
reg04: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back
reg05: base=0x13c000000 ( 5056MB), size=   64MB, count=1: uncachable
reg06: base=0x0e0000000 ( 3584MB), size=  256MB, count=1: write-combining

Y lo que nos interesa para nuestro “performance”, obtenemos unos 450 FPS de promedio (eso es casi 50% de mejora):

glxgears -info
GL_RENDERER   = Software Rasterizer
GL_VERSION    = 2.1 Mesa 7.7.1
GL_VENDOR     = Mesa Project
2277 frames in 5.0 seconds = 455.288 FPS
2314 frames in 5.0 seconds = 462.779 FPS
2251 frames in 5.0 seconds = 450.191 FPS

Conclusiones

Mucha gente monta GNU/Linux Debian o Ubuntu de manera genérica y como *cae* al disco duro, comienzan a usarlo y lo sienten “pesado” sin olvidarse de la necesidad imperiosa de “enchular” la computadora para mejorar el rendimiento y así gozar de una experiencia más placentera al usar nuestro GNU/Linux.

¿Pruebas?

Me dediqué a sacarle “provecho” a la aceleración 3D, con 500 FPS no son los 2000 FPS que logra mi Nvidia 8400 SLI del Desktop pero esta es una portatil!.

Para muestra, podemos ver una pantallazo interesante:

Aca podemos ver a Billard-GL (un juego de Billar 3D que usa SDL y openGL) a pantalla completa.

Pero para mejores pruebas, tenemos esto:

Fijense que tengo cargados tanto Compiz (icono superior, fusion-icon), como Billard-GL y además, a ExtremeTuxRacer (reportando a 40FPS) y el Firefox cargado (para consumir RAM obviamente).

Para probar la aceleración openGL + la extensión xvMC cargames un video y corremos el efecto “cubo” de compiz, el video no debería “ralentizarse” nunca.

Espero que logren disfrutar sus juegos 3D y su compiz a full efectos!.

de Lenny a Squeeze: Cambios en la configuración de Video: Intel

Uno de los cambios que sorprenderá más a los usuarios de Debian que pasen a Squeeze o aquellos de ubuntu (o trisquel, canaima, etc) que pasen de la versión 9.04 en adelante, es en la forma como se debe configurar las X (sistema gráfico de Linux); anteriormente estabamos acostumbrados al archivo /etc/X11/xorg.conf y pues ahí colocabamos toda la configuración, ahora, no es así.

Cambios en la estructura de configuración

Aunque por compatibilidad “aun” podríamos tener un archivo en /etc/X11/xorg.conf; la forma “oficial” de configurar es agregar un archivo en:

/usr/share/X11/xorg.conf.d/

NOTA: Hasta las primeras “preliminares” se encontraban en /usr/lib/X11/xorg.conf.d/, esto aún se mantiene así en Ubuntu, Trisquel y otros derivados, en Debian Squeeze se encuentran en /usr/share/X11/xorg.conf.d/

Donde encontraremos una serie de archivos, ordenados por número:

-rw-r--r-- 1 root root  946 2010-03-31 01:59 05-evdev.conf
-rw-r--r-- 1 root root  766 2010-04-15 17:07 10-synaptics.conf
-rw-r--r-- 1 root root  139 2010-04-22 10:44 10-vmmouse.conf
-rw-r--r-- 1 root root 3201 2010-07-03 20:46 15-wacom.conf

Cada archivo carga en el orden de acuerdo a su numeración, comenzando desde 05-evdev.conf (que contiene la configuración oficial del teclado, ratón y resto de dispositivos de entrada), hasta el resto de archivos.

Nombres de las secciones

Antes, uno colocaba el nombre de las secciones y luego usando la directiva “ServerLayout” indicabas qué representaba cada sección, aunque podríamos hacerlo, el xorg ahora “detecta” cada cosa y le coloca un nombre, por ejemplo ahora la sección “video” se llama:

"Configured Video Device"

Y si haz de hacer referencia a la configuración de tu tarjeta de video, entonces la nombrarás así:

Section "Device"
Identifier    "Configured Video Device"
...
EndSection

Tarjetas Intel (>950)

Para tarjetas de video Intel, creamos un archivo llamado:

/usr/lib/X11/xorg.conf.d/10-screen.conf

Y agregamos la siguiente información:

Section "Device"
 Identifier    "Configured Video Device"
 Driver          "intel"
 Option          "AllowGLXWithComposite" "true"
 Option          "XAANoOffscreenPixmaps" "true"
 Option          "AddARGBGLXVisuals"     "True"
 Option          "DRI"   "True"
#        Option          "AccelMethod"   "EXA"
#        Option          "AccelMethod"   "XAA"
 Option        "AccelMethod"     "UXA"
 Option        "EXAOptimizeMigration"        "true"
 Option        "MigrationHeuristic"        "greedy"
 Option        "Tiling"            "true"    
 Option        "NoDDC"
 Option        "BackingStore"    "True"
 Option         "AIGLX"  "true"
 Option          "MTRR" "on"
 Option          "UseFBDev" "false"
 Option          "LinearAlloc" "6144"
 Option          "MonitorLayout" "CRT,LFP"
 Option          "DevicePresence" "true"
 Option          "RenderAccel" "true"
 Option          "RandRRotation" "on"
EndSection

El Driver, seguirá siendo “intel” pero vemos que contamos con al menos 3 métodos de aceleración, UXA, EXA y XAA, como DRI (y DRI 2) han sido eliminados de Xorg; entonces debemos utilizar los modos nativos de las tarjetas Intel para aceleración 2D y 3D, explicaré cada uno.

XAA (Xfree86 Accel Architecture): La forma nativa y básica, usa DRI y es la forma más eficiente para 2D, además es la por defecto.

EXA: Reemplazo para XAA, simplemente permite utilizar openGL tanto para las aceleraciones 2D y 3D, si tu tarjeta de video soporta aceleración openGL, entonces EXA provee un equilibrio entre el uso de 2D y 3D; si deseas usar Compiz, esta opción es más eficiente que XAA puesto que permite activar la opcion “COMPOSITE” de tu tarjeta de video.

UXA: La re-implementación de EXA para soportar mejor estabilidad, eliminar el uso de DRM (Direct Rendering Manager) y uso de modos nativos para tarjetas INTEL, reemplaza además a TTM por GEM con lo que la memoria de la tarjeta de video es gestionada más eficientemente; como DRI/DRI2 fueron diseñados en el tope de TTM, no se puede usar UXA sin desactivar DRI entre los módulos.

En Soporte a UXA/GEM en el Kernel desde 2.6.28 hace que en Squeeze ya se pueda usar UXA como modo nativo (y más eficiente) de aceleración.-

De hecho, en Ubuntu 9.10 se cambió de EXA a UXA el modo nativo de rendering si se detecta una tarjeta Intel.

Entonces:

  • Si tu tarjeta Intel es nueva (965, GM300, etc) no lo dudes, usa UXA
  • Si tu tarjeta Intel es viejita, usas EXA si deseas Compiz
  • Para entornos con poco consumo de video (fluxbox, etc), aceleración 2D basada en XAA y DRM es más que suficiente para ahorrar memoria.

Heurística de Migración

La opción:

MigrationHeuristic

Tiene varias opciones posibles, de acuerdo al modo que escojan:

  • Si usan Gnome, SOLO con aceleración 2D, entonces: EXA+MigrationHeuristic = greedy
  • Si usan KDE y aceleración mixta: UXA + MigrationHeuristic = Smart
  • Si cambian a UXA y Heuristict=Smart, deberán agregar:
Option Tiling "true"

Que permitirá corregir errores de Tiled Rendering (Ubuntu Bug)

La configuración OPTIMA pasa por usar entonces:

  • AccelMethod = UXA
  • MigrationHeuristic = smart
  • Tiling  = true
  • MTRR = on
  • Option VideoRAM 262144 (256MB de Video RAM)

Y alternativamente agregar esto como líneas de arranque en el grub (para evitar un bug de MTRR):

mtrr_spare_reg_nr=1 enable_mtrr_cleanup

Y por último agreguen esto en el /etc/environment:

INTEL_BATCH="1"

Cuando tengan todo listo, en resumen:

  • Archivo 10-screen.conf
  • Cambios en el /etc/environment
  • Cambios en el grub (sea por /etc/default/grub y rehacer el grub.cfg o en menu.lst)

Reinicien el equipo.

¿Qué causaran estos cambios?

  • Podrán ver videos de Flash en FullScreen
  • Podrán ejecutar videos de resolución HD (720) en VLC o mplayer
  • Tendrán un equilibrio perfecto entre 3D y 2D

Observaciones

Para usuarios Ubuntu/Trisquel y en respuesta a un Bug, les recomiendo además de (por cambios hechos en el Kernel de Ubuntu) cambiar lo expuesto arriba, agreguen la siguiente opción en el archivo:

/etc/rc.local

La siguiente línea:

echo "base=0xc0000000 size=0x10000000 type=write-combining" >  /proc/mtrr

O en su defecto, seguir las instrucciones de esta guía:

http://ubuntuforums.org/showthread.php?t=1130582

A %d blogueros les gusta esto: