For everything else, like running ARM software on x86 (and vice versa), you'll have to resort to emulation, which involves either interpreting the code or dynamically recompiling it. By definition, you can emulate anything on anything else (someone recently booted Linux for MIPS on an Intel 4004, the first ever microprocessor), but the performance might be a problem.
This is also less of a QEMU problem and more just that ARM does not emulate well on x86_64 due to their designs.
ARM Linux is close to usable, however.
Only emulating the portion of the instruction set available from the userspace is another story though. At least the way Apple does it with Rosetta and Microsoft with whatever their thing is called, you don't even notice that an app is running under emulation. The only giveaway is that it takes a noticeable time to start for the first time while the code is being translated. It's truly impressive.
It seems the main obstacle is in paging where x86 4KB clashes with Apple 16KB (ARM/64 supports multiple sizes), so, 2-level paging canʼt aid and an emulator has to shadow-paging which is, definitely, much slower.
> Apple does it with Rosetta and Microsoft with whatever their thing is called, you don't even notice that an app is running under emulation.
But they still use a vendor-specific TSO support in hardware.
A simple approach would identify basic blocks in the code and translate them to an IR for an optimizing compiler back-end like LLVM.
Of course, you have to be careful with self-modifying code.
UTM might do what you want but likely not on x86.
> Virtualize macOS as well.
> Run multiple instances of macOS on your Apple Silicon Mac with UTM. This can be useful for developers as well as security conscious users.
> Note that macOS VM support is limited to ARM based Macs running macOS Monterey or higher.
What is ARM hardware in this case? Did you mean the T2 processor on Intel Macs?