2

On x86-64 Linux, there are two options for running 32-bit applications: one can be built into the kernel itself via the option CONFIG_IA32_EMULATION (normally on for most kernels), and the other is qemu-i386.

What are the differences? Can qemu-i386 run near native performance – it is more like native, or is it more like a JIT recompiler?

1 Answer 1

4

The kernel config option CONFIG_IA32_EMULATION offers the possibility for an x86-64 kernel to support the execution of 32 bit binaries.
This support essentially consists in

  • offering entry points for i386 system calls. (i386 and x86_64 have different syscall numbers) and converting 32 bits arguments to 64 bits.
  • hacking the ELF-loader (fs/binfmt_elf.c, which is responsible for loading an executable out of a file-system and into a process's address space to start executing) in order to conform to 32 bits ELF files structures.

32 bits binaries can then be executed without needing any additional layer between them and the kernel.
Some short history of nasty vulnerabilities (all scrupulously patched but… one never knows)

qemu-i386 (as you asked for it, v.g. not qemu-system-i386) is a user space emulator. i.e. a program executing in userland and responsible for loading the 32-bit internally, convert 32 bits system calls into 64 bits system calls etc… without requiring any special 32 bit support from the kernel.

This major difference (the additional layer running in userland) makes you just cannot expect reaching near-native performances with qemu-i386 (just think at running Windows programs thanks to Wine), adding to this miscellaneous possible troubles with dynamically linked executables and the need for dedicated tools when willing to debug the 32 bits application.


EDIT following OP re-edition about qemu :

it is more like native, or is it more like a JIT recompiler?

As we can read from Translator Internals, qemu is a dynamic translator based on the “Tiny Code Generator” which, as a backend is nothing but a (abstract)code generator.
Since that abstract code will then be translated into the specific target's machine code (with some amount of optimization), that abstract code might be said compiled.
Therefore we are indeed closer to some sort of JIT compiler (of code) than to native (execution of code)… althought… "Just In Time" could be… questioned… ;-)

2
  • Oh, duh, I missed the significance of qemu-i386. The ELF “hacking” is very minor, all that happens is that ARCH_DLINFO_IA32 is added and the vDSO is made available. There’s more to the syscall handling than the varying syscall numbers: i386 and x86-64 have different syscall mechanisms (SYSCALL, SYSENTER, interrupt 0x80). Jan 18 at 11:55
  • IA-32 Linux syscalls are generally done by either int 0x80 or vDSO. SYSENTER is rigged with pitfalls for assembly usage (thanks to vDSO), and SYSCALL is not available for Intel processors outside long (64-bit) mode.
    – mcendu
    Jan 18 at 14:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .