Emulating aarch64 in software using JIT compilation and Rust

Reusing the work-in-progress QEMU code is awesome!

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.

▲

bonzini 3 days ago | parent [-]

Yep, vm-memory needs pretty large changes to the crate itself but fortunately they're already in progress to add IOMMU support to the virtio and vhost crates. Probably there will be an API break but with old and new crates able to talk to each other so you don't need a flag day.

I am curious if you get to DMA before or after QEMU, and if before what your API will look like.

	▲	epilys 3 days ago \| parent [-]
		Very little free time unfortunately... Haven't spent many hours on this project.

▲

lionkor 3 days ago | parent | prev [-]

This is a common issue in the Rust world, I think, but I wanted to point it out; I was looking forward to seeing someone build a little minimal JIT for this.

Instead the author uses Cranelift[1] and binja to solve the two interesting problems here.

While cool, I'm not sure if that's interesting enough to read through in its entirety. I use libraries all day every day, but is it the hacker spirit to make your entire project glue-code for libraries that do the thing you claim to do?

It's maybe more philosophical than anything.

1: https://cranelift.dev/

▲

epilys 3 days ago | parent | next [-]

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.

(Author here)

▲

kmarc 3 days ago | parent | prev | next [-]

> is it the hacker spirit

I had this philosophical / existential crisis question lately about my project, and I think I'm at peace with it.

Yes. Gluing together stuff (AKA building on other giants' shoulders) can be done in a neglecting, "just hack it all up until starts to work" way, and it can also be done in a reproducible, "unit tested", documented way that enables you to eventually put even more "hacks" on top of it to deliver value.

Anything is "hacker spirit", as long as you make something _functional_ out of pieces that haven't functioning in a way you wanted before. Let it be witty, hackish, or beautiful, maintainable, as long as it holds up your business or gives you simply joy.

	▲	ashdnazg 3 days ago \| parent [-]
		Yes, and I would even go as far as saying that even being functional isn't required. Trying to make something cool and failing counts as "hacker spirit". It all boils down to getting your hands dirty, instead of passively consuming the products of others.

▲

jdright 3 days ago | parent | prev | next [-]

I read this comment and the only thing I can think of is about the infamous Dropbox comment[1].

ps. I'm not saying this project has the same potential as Dropbox or otherwise.

[1] https://news.ycombinator.com/item?id=9224

▲

clfdev 3 days ago | parent | prev | next [-]

this is like telling someone who wrote their own game engine from scratch that they're missing the hacker spirit because they rely on mesa to compile their shaders rather than writing their own compiler for every single GPU they support

▲

MSFT_Edging 3 days ago | parent | prev | next [-]

> but is it the hacker spirit to make your entire project glue-code for libraries

Literally in the name to hack things apart and hack them back together. It's about taking some unrelated bits and making something from it.

▲

tonyedgecombe 3 days ago | parent | prev [-]

Yes, it somewhat reminds me of all the projects that claim to be a PDF reader only to have GhostScript do all the hard stuff.

▲

quotemstr 3 days ago | parent [-]

Or all those JavaScript "compilers" that don't compile anything, but instead stick a binary blob onto the end of a prebuilt Bun binary --- or worse, just wrap Bun's implementation of this blob-appending and not even earn the watered-down "compiler" label. Accomplishment inflation isn't going to end well.

	▲	bitwize 3 days ago \| parent [-]
		Or those Sams Visual Basic books that taught you to "build your own web browser" by dropping the IE component and some buttons and stuff on a form.