Due to the issues with Sedna, considering moving to QEMU/KVM virtualisation on the host machine

[DecDuck]

Is your feature request related to a problem? Please describe.
From my understanding, development is paused because the underlying Sedna library has an unknown issue causing compilation issues.

Describe the solution you'd like
Dropping the pure-Java Sedna library in favour of QEMU/KVM backed virtualisation might make sense.

Describe alternatives you've considered
There are a number of RISC-V pure-Java libraries out there (see here) that could be used.

Additional context

[DecDuck]

See also RVVM & JNI

[CoolCat467]

Might be smart using discussions for this instead of issues, but I'm just someone interested in this project and have no authority

[atirut-w]

discussions

I usually just give them the boilerplate "See also: (link to discussions tab)" reply or something similar.

[DecDuck]

Good idea

See also #281

[SergSel2006]

The idea of migrating to QEMU is good. Though, you must have qemu installed alongside if it is the only VM.
I don't think normal users would go and install some 3rd party program just to run the game.

[ajh123]

The idea of migrating to QEMU is good. Though, you must have qemu installed alongside if it is the only VM. I don't think normal users would go and install some 3rd party program just to run the game.

Maybe one of those other Java implementations should be used by default and QEMU/KVM should be used if it is detected or enabled in configs?

[DecDuck]

The problem is there aren't any great other Java-based emulators. A quick Google search puts Sedna at the top (the library it's currently using, and has issues with) and https://github.com/CN-GuoZiyang/rvemu, which has no documentation and doesn't seem like it has ongoing maintenance or development.

[SergSel2006]

The problem is there aren't any great other Java-based emulators. A quick Google search puts Sedna at the top (the library it's currently using, and has issues with) and https://github.com/CN-GuoZiyang/rvemu, which has no documentation and doesn't seem like it has ongoing maintenance or development.

If we talk on topic of this issue, we have qemu clients in java. For example, a qemu-java
only thing is to make use of it, which is not that simple.

[CoolCat467]

I think the ideal solution would be to get Sedna working again by trying to recreate the issues without requiring minecraft on top of it

[JohnTheCoolingFan]

Absolutely agree. We need a simple frontend for sedna to make testing and debugging easier.

[DecDuck]

Sedna is definitely the best solution for most people, but by implementing QEMU emulation, we're also implementing a generic interface so we can add any emulation backend.

[CoolCat467]

Sedna is definitely the best solution for most people, but by implementing QEMU emulation, we're also implementing a generic interface so we can add any emulation backend.

True, and if anyone else implemented a VM in the future that followed whatever specification would be required, it would be much easier to swap it in. +1 for generic interface.

[atirut-w]

True, and if anyone else implemented a VM in the future that followed whatever specification would be required, it would be much easier to swap it in. +1 for generic interface.

Is that also a prerequisite for supporting other architectures?

[ajh123]

True, and if anyone else implemented a VM in the future that followed whatever specification would be required, it would be much easier to swap it in. +1 for generic interface.

Is that also a prerequisite for supporting other architectures?

Yes, unless they get baked into Sedna.

[IntQuant]

Seems like that sedna issue has been fixed in this pull request.

[TheOverpassArsonist]

Seems like that sedna issue has been fixed in this pull request.

1 : holy shit, that's great, I legitimately thought this was going to be a great mod that just died due to a single technical bug, but
2 : I do think there is still some merit to the QEMU discussion. If that fix really does work then it's not a "necessary to continue" thing anymore, but I can still see the argument for adding a QEMU interface. At the risk of being language-ist, as far as I'm aware java's JVM design is intrinsically a bit limiting, particularly for performance and hyper-optimization. Qemu/KVM however were built from the ground up knowing that they'd need to do full emulation, and do it really well.

There are a few obvious issues here though
2.1 : it's no longer necessary, so would be a lot of work for questionable return
2.2 : native virtualization/emulation exposes some potential security risks - I don't think things like Zenbleed or the recent M2 key-extraction things could have been meaningfully leveraged in a Java virtual machine (as in, Sedna, not JVM) but Qemu and KVM could have allowed someone on your minecraft server to get access to your actual device's data.
2.3 : care would have to be taken to ensure virtual computers in minecraft can't bring the host's real world computer to a crawl (sort of a subset of 2.2, but less about intentional malicious attacks and more about "oh, one of the players on my server wrote a "while true" loop)

With that said, it'd allow for much more architecture flexibility and would modularize things a lot in a way Sedna alone just can't hope to. I wouldn't go as far as saying to replace Sedna (especially since Sedna now seems to work!) but I can definitely see the merits of at least considering adding a Qemu interface. For instance, I did a quick search and found this which indicates that there are ways to use cards to hardware-accelerate virtualization. So, assuming Qemu has support for these sorts of things, (which, to be clear, I am blindly assuming - I am a complete virtualization noob) something like an optional Qemu interface to replace Sedna would allow a host to buy a simple PCIe card to dramatically reduce the server load of OC2. Alternatively, a QEMU interface could be used to make OC2 more architecturally agnostic itself, fronting that responsibility onto QEMU instead. In that case x86 systems could be virtualized instead of emulating ARM systems and, assuming OC2 could keep a tight enough leash on QEMU, it would be great for performance. The "virtual" computers in OC2 could have performance equivalent to if they natively had whatever hardware they were given in-game, without any (significant) overhead for the host.

It's definitely not a cut and dry "do this" or "don't do this", but I think there are merits and costs here that seperate it from simply being a possible Sedna replacement, even if Sedna now works. Especially for people who host servers using online hosts I imagine you could do some wild integration, for instance maybe leasing some amazon server and using it for virtualization while your game-server runs on a completely different service. In a case like that you could potentially even lease your servers as needed in order to support whatever OC2 computers are currently in loaded chunks or do something else wild with the integration.

[spike11302000]

so 2.3 afailk how senda is implemented into oc2 is that each computer has a set amount of instruction/tick so if some one does a "while true loop" it wont affect the host at all and given that i is single thread if you where to build more computer the computers them self would get slow instead of the host. but if you use qemu each instance has 1-4 threads for each computer so it will consume way more ram and will cause the host to lag if there isnt enough cores. i feel like senda is a way better option here as it gives way more control on how the computer execute. if more performance is desired it might be better to rewrite the cpu core in c/c++ and use JNI to interface (like oc1 did with lua) with it but this will also require creating ports of the binary for different os/architectures.

[ajh123]

Furthermore, I wonder how power usage would be added to QEMU, since with Senda every time an instruction is executed a bit of energy is used. I'm not sure if QEMU allows this to be tracked. The biggest reason why OC / OC2 was great is the realism - having computers require power is realistic and would provide a harder challenge.