Qué son i440fx y Q35
Toda máquina virtual de QEMU tiene un chipset virtual. Define la placa base virtual entera — la topología de bus PCI/PCIe, el puente sur, el controlador de interrupciones, lo que el SO invitado ve cuando enumera el hardware al arrancar.
QEMU ofrece dos opciones: i440fx y Q35.
i440fx emula el Intel 440FX — nombre en clave Natoma, lanzado en 1996 como el chipset para el Pentium Pro y, más tarde, el Pentium II. Presenta un bus PCI plano sin soporte nativo de PCIe. Fue el tipo de máquina original de QEMU y ha sido el por defecto durante mucho tiempo. No está mal para un chipset diseñado para el Pentium Pro.
Q35 emula el Intel Q35 Express, lanzado en junio de 2007 para la generación Core 2, emparejado con el puente sur ICH9. Le da al invitado un complejo raíz PCIe en condiciones y un controlador de interrupciones moderno. Los dispositivos pasados por passthrough aparecen como dispositivos PCIe nativos con la topología correcta.
Ambos son virtuales. Ninguno afecta al hardware real que usa el host. La diferencia está en lo que ve el SO invitado.
Por qué Q35 importa para el passthrough
Los dispositivos pasados a una VM i440fx aparecen como dispositivos PCI heredados sin importar lo que sean en realidad. El invitado los ve como «dispositivos PCI muy rápidos» en vez de dispositivos PCIe. Algunos controladores funcionan bien así. Otros esperan PCIe y se comportan mal o se niegan a cargar cuando no lo encuentran.
El complejo raíz PCIe de Q35 cambia el cuadro de varias maneras.
MSI-X
MSI-X (Message Signalled Interrupts — Extended) requiere PCIe. Bajo i440fx, MSI-X o recae en interrupciones INTx heredadas o directamente no funciona.
Esto importa mucho para NVMe. Las controladoras NVMe dependen de MSI-X para su arquitectura multicola. Cada par de colas de E/S obtiene su propio vector de interrupción. Sin MSI-X, todas las finalizaciones de E/S se embudan por una única interrupción, lo que crea un cuello de botella con muchas IOPS.
También importa para las tarjetas de red modernas y las GPU. Cualquier dispositivo que use múltiples vectores de interrupción para repartir carga entre núcleos de CPU necesita MSI-X.
AER (Advanced Error Reporting)
El AER de PCIe permite al invitado detectar y manejar los errores del dispositivo en condiciones en vez de fallar en silencio. Bajo i440fx, el invitado no tiene visibilidad de los errores a nivel PCIe.
Para una carga de producción con un dispositivo pasado por passthrough, tragarse los errores en silencio es un problema. El AER le da al controlador del invitado la capacidad de registrar, informar y en algunos casos recuperarse de errores de hardware que de otro modo pasarían inadvertidos hasta que los datos se corrompen.
ACS (Access Control Services)
El ACS controla el DMA punto a punto entre dispositivos del mismo bus. Es parte del modelo de aislamiento del IOMMU. Impide que un dispositivo haga DMA sobre el espacio de memoria de otro sin pasar por el IOMMU.
Bajo i440fx, la topología de bus virtual no admite ACS en absoluto. Esto no rompe el passthrough básico, pero debilita el aislamiento que se supone que te da el IOMMU.
Presentación de grupos IOMMU
La jerarquía PCIe de Q35 significa que cada ranura virtual puede sentarse en su propio grupo IOMMU dentro del invitado. i440fx amontona todo en un bus compartido, lo que hace problemática la configuración del IOMMU del lado del invitado.
Esto es relevante para la virtualización anidada, donde el propio invitado necesita grupos IOMMU limpios. También es relevante para vIOMMU, que solo está disponible en Q35.
vIOMMU
Si necesitas que el propio invitado tenga capacidad IOMMU — para passthrough anidado, para DPDK o para ciertas configuraciones de seguridad — eso requiere el tipo de máquina Q35.
La emulación vIOMMU deja al invitado ejecutar su propio IOMMU, lo que es útil para:
- Passthrough de VM anidada (una VM dentro de una VM con acceso a dispositivos)
- Redes DPDK en espacio de usuario donde la aplicación necesita protección IOMMU
- Configuraciones de seguridad que requieren aislamiento DMA dentro del invitado
Por qué Q35 importa más allá del passthrough
Aunque no estés haciendo passthrough, Q35 es la mejor elección para cargas modernas.
Firmware OVMF (UEFI)
La combinación de Q35 y OVMF le da al invitado un entorno de arranque UEFI moderno con soporte de Secure Boot. i440fx puede usar OVMF pero la combinación está menos probada y algunas funciones no van bien.
Windows 11 requiere UEFI con Secure Boot. Los requisitos de hardware de Microsoft lo exigen. Windows Server 2025 funciona mejor con UEFI. Q35 con OVMF es el camino soportado para ambos.
Si estás ejecutando una VM de Windows 11 o Server 2025 sobre i440fx con SeaBIOS, estás peleándote contra la corriente. Puede que funcione hoy. No es hacia donde va el ecosistema.
AHCI
Q35 incluye emulación AHCI (Advanced Host Controller Interface) nativa a través del puente sur ICH9. i440fx usa la emulación IDE más antigua o LSI SCSI para los discos de arranque.
Para almacenamiento VirtIO esto no importa. VirtIO se salta por completo la controladora de almacenamiento del chipset. Pero si estás usando emulación SATA para un SO invitado que carece de controladores VirtIO en el momento de la instalación, AHCI en Q35 es mucho más rápido que IDE en i440fx.
La sobrecarga que i440fx acarrea y Q35 no
La brecha de AHCI no es solo cuestión de que una controladora sea más nueva. Es que i440fx hace que el invitado le pague al hipervisor en casi cada interacción, y Q35 en su mayoría no.
Acceso a registros atrapado. El IDE se programa a través de puertos de E/S x86 heredados. El invitado escribe el número de sectores, luego los registros LBA, luego el registro de orden. Cada escritura toca un puerto distinto. Cada uno de esos accesos es atrapado y emulado por el host, y cada trampa es una salida de VM que cuesta microsegundos de un solo dígito. Emitir una orden IDE cuesta por tanto varias salidas antes de que se mueva dato alguno.
AHCI funciona al revés. El invitado construye una tabla de órdenes en su propia RAM — sin trampas, porque no es más que escribir en memoria — y luego hace una escritura MMIO a un registro-timbre para decirle a la controladora que la recoja. Una orden cuesta más o menos una salida en vez de cinco o seis.
Sin encolado de órdenes. El IDE emite una orden y espera a que termine. AHCI admite NCQ, así que puede haber hasta 32 órdenes pendientes, y la unidad es libre de completarlas fuera de orden para reducir el desplazamiento del cabezal. Como tal, el coste por orden restante se reparte por una cola en vez de pagarse de uno en uno.
El camino de interrupción heredado. La controladora IDE PIIX3 señala la finalización en las IRQ heredadas fijas 14 y 15, entregadas como INTx disparadas por nivel. Una interrupción disparada por nivel tiene que reconocerse y desenmascararse, y como las líneas INTx son compartidas, el invitado también debe averiguar qué dispositivo la levantó. Cada uno de esos pasos es otra trampa. MSI-X, que necesita Q35, es una simple escritura en memoria sin línea compartida que identificar y sin viaje de ida y vuelta de reconocimiento. En hardware con interrupciones diferidas puede llegar al invitado sin salida alguna.
Una mayor superficie de dispositivos heredados. i440fx siempre presenta sus dispositivos de plataforma heredados, incluida la controladora IDE, use la VM o no. Ocupan ranuras PCI, se enumeran y sondean en cada arranque, y los controladores del invitado pueden consultarlos. Q35 presenta un juego más pequeño y moderno. Menos que aguantar para el host, menos que recorrer para el invitado.
Nada de esto aparece en una VM respaldada por VirtIO, y por eso la diferencia es fácil de pasar por alto. Importa durante la instalación, en imágenes de appliance sin controladores VirtIO, y en cualquier invitado que aún use SATA o IDE emulado para su disco de arranque.
Menos dispositivos virtuales, topología más limpia
i440fx viene con hardware virtual heredado que Q35 deja fuera. Una tarjeta de sonido de pega. Una controladora IDE heredada. Ninguna hace nada útil, pero ambas queman ranuras PCI virtuales y pueden confundir al software del invitado que intente usarlas.
Q35 presenta un juego de hardware virtual más limpio que se parece más a lo que expondría un servidor físico moderno.
La dirección del viaje
RHEL 10 ha declarado obsoleto i440fx
Red Hat ha declarado formalmente obsoleto el tipo de máquina i440fx en RHEL 10. Eso marca la dirección del viaje para todo el ecosistema KVM. Cuando Red Hat declara algo obsoleto, significa que han dejado de probarlo como camino de primera clase y no arreglarán los fallos atados a él.
El proyecto QEMU upstream lleva años debatiendo la obsolescencia de i440fx. El consenso es que mantener dos caminos de chipset es una carga. Q35 es el que se corresponde con el hardware moderno.
Proxmox no ha seguido
Proxmox VE sigue creando las VM nuevas como i440fx. El tipo de máquina en el asistente de creación pone «Default (i440fx)», y así se queda a menos que lo cambies. Q35 está a un desplegable de distancia, pero es una elección que tienes que hacer a propósito, en cada VM que construyes.
Esa es la razón entera de que este post exista. El por defecto es el chipset de 1996, y nada en el asistente te dice que la elección importa.
Cambiar una VM existente
Si tienes una VM existente en i440fx, puedes cambiar a Q35 en los ajustes de hardware o directo en la configuración:
machine: q35
Esto es en la práctica un cambio de placa base virtual. Hardware distinto en el siguiente arranque.
Linux en general maneja esto sin problema.
El kernel reenumera los dispositivos y carga los controladores correctos.
Los nombres de interfaz cambiarán porque la NIC virtual pasa de un bus PCI a un bus PCIe.
Si tu configuración de red los nombra (p. ej. eth0, ens18), actualízala antes de reiniciar o pierdes el acceso a la red.
Windows es menos indulgente. El cambio de chipset significa IDs de hardware virtual distintos para la controladora de almacenamiento, el adaptador de red y otros dispositivos de plataforma. Windows puede necesitar reinstalar controladores. En algunos casos una instalación limpia es el camino más limpio. El Windows más viejo es el infractor habitual.
FreeBSD y derivados (OPNsense, pfSense) en general manejan el cambio, pero prueba primero.
En todos los casos, prueba en una VM que no sea de producción antes de cambiar nada que importe.
Cuándo aún hace falta i440fx
Un puñado de casos aún necesitan i440fx.
Sistemas operativos invitados heredados anteriores a UEFI — Windows XP, Windows 2000 y similar cosecha — pueden no arrancar bajo Q35. Estos SO esperan la topología PCI heredada y el SeaBIOS que aporta i440fx.
Ciertas imágenes de appliance están construidas y probadas exclusivamente contra i440fx. Si el fabricante solo soporta i440fx, eso es lo que usas hasta que lo actualicen.
Para todo lo demás — VM de Linux nuevas, Windows moderno, cualquier carga con passthrough — usa Q35. No hay nada que ganar aferrándose a un chipset de 1996 por costumbre.
Referencias
- Proxmox VE Wiki — PCI(e) Passthrough — documentación oficial de Proxmox que señala Q35 como el tipo de máquina recomendado para el passthrough
- QEMU Q35 Chipset Specification (PDF) — el documento de diseño original de QEMU Q35
- Proxmox Forum — Q35 vs i440fx Discussion — debate de la comunidad que cubre las diferencias prácticas