Why is QEMU only available for x86_64?

According to the package information pages here and here, the QEMU packages are only built for x86_64 target. There are 3 things I want to ask:

  1. Why are QEMU and KVM not available for ARM and MIPS architectures? I really want to try out emulating an x86 machine on my ipq4019 router then install Windows XP on it. The CPU may be weak, but it has 512Mib of RAM, which is more than enough to do it.
  2. Why is the package name qemu-x86_64-softmmu instead of qemu-system-x86_64 like desktop distributions call it? I know it doesn't matter, but it sounds confusing to me at first.
  3. It seems the package information database is outdated. Right now it states that the version is 5.0.0, but in fact it is 6.2.0 on OpenWrt 22.03 already.

qemu-kvm can only virtualize CPU in same arch. softmmu is for emulation, might be very slow.
there is CONFIG_KVM for aarch64/riscv in kernel but not enabled in openwrt. raspberry pi 4 owners could enjoy windows 10/11 arm64 VMs in kvm.

qemu-kvm ist one of those packages that need rather a lot of target-arch specific packaging, apart from bootloader and kernel configuration allowing it to run in the first place (and the target board having a supported CPU, enough RAM and reasonably fast I/O to boot a VM). If you want to use qemu on ARM for OpenWrt, you're probably the one to get it working and properly packaged in the first place (not that many others may want to use qemu on their router, even if CPU/ RAM and bootloader would allow it in the first place); x86_64 is just a little easier in this regard.

Yeah. qemu to allow x86 binaries to run on aarch64 with binfmt_misc might in theory be viable on some of the beefier aarch64 devices (Pi4, RK3399, RK3588) if you have some oddball amd64 or x86 Linux binary you REALLY need to run for some odd reason. But ipq4019 is a bit too weak for anything but the most minimal x86 binaries, and the OP's use case of Windows - no, that's not gonna happen, among other things the complete lack of graphics capability in an ipq4019.

I would already have my doubts if the (various) bootloader(s) initializes the right mode (PSCI?) to use kvm at all (virtualizing ARM on ARM, x86 is totally beyond sanity). RPi, sunxi, rockchip, sure, there you can get that working, but ipq40xx, ipq806x, ipq807x, mvebu, mt7623, mt7622 are a totally different topic, especially in terms of bootloader specifics. Either way, it would need someone to do target specific, ground-up research and develoment work to extend the qemu packaging for ARMv7/ ARMv8.

among other things the complete lack of graphics capability in an ipq4019.

It doesn't matter because QEMU uses the CPU to emulate the GPU of the virtual machine anyway, unless you want to use the para-virtualized virtio-gpu-pci which is useless for Windows guests.

@slh I did not really expect the problem was because of packaging. I always thought that recompiling and packaging is a daily task in Linux world. I had only a little experience with C++ development in the past, so I don't understand such low level stuffs well enough.

It still needs someone to do the task on and for ARMv7, it doesn't do itself.

Btw. the 'easiest' approach to this would be:

  • start with a known good base
    • e.g. Debian/ ARMv7 on RPi2+, sunxi or rockchip
      • take notes what they do to get it working
        • bootloader configuration
        • kernel configuration
        • qemu configuration and packaging
      • assemble a known good virtio VM
  • try to replicate this on OpenWrt, sticking to the same 'easy' SBC environment (RPi2+, sunxi, rockchip)
  • once you have this working and can boot/ use your previously created ARMv7 VM, you may start to look at more "router'ish" platforms (ipq40xx, ipq806x, ipq807x, mt7623, mt7622, mvebu/ARMADA, etc.)
    • the typically ancient OEM bootloaders and their configuration (does it move the ARM core to PSCI) will probably pose quite some issues here.
    • OpenWrt's kernel configuration will likely require additional settings (which would be hard to justify for a default image)
    • static user mode emulation with binfmt would be quite another endeavour
    • RAM size probably puts a halt on (realistic) usage for quite a few devices
    • I/O performance might be detrimental quite quickly as well (especially with something as demanding on I/O performance and IOPS)
    • emulation of foreign architectures (x86_64 on ARM) is a completely different can of worms on top of that)

Possible? Sure, everything is, given enough dedication and efforts spent - but far from trivial (even with the aforementioned 'cheating' of taking a look what the big boys do on SBC like platforms). It's not as simple as adding a config symbol here or there and adjusting some dependencies.

1 Like