Writing a JIT and a disassembler are completely separate topics than emulating a system, don't you agree? :D (The article only talks about structuring a system emulator.)
The disassembler is my next step, since it's the easiest to tackle. Swapping binja for a custom solution on the existing code would be relatively straightforward.
The JIT is a completely different beast, it's essentially the IR -> codegen steps of a compiler (meaning without parsing, syntax/lexical analysis, object generation). Seeing as I wanted to target both x86_64 and aarch64 hosts, using an existing solution would get me started faster before I eventually write my own.
My plan is to split the JIT backends and keep cranelift for x86_64 support, but have my own aarch64 JIT also.
You have to pick your battles and assign priorities, you cannot re-invent everything at once.
Yes! I also started with using vm_memory traits in the beginning but delayed it till I refactor my memory subsystem. When we get that in upstream QEMU it might be possible to share this implementation as well as future devices.
Yes, it's possible and supported. QEMU can emulate an aarch64 system, and Google provides aarch64 Android builds for virtual machines specifically, called "Cuttlefish". Search for keywords "Android Cuttlefish QEMU" for instructions.
(Thanks for cargo-nextest btw!)