• henfredemars@infosec.pubEnglish
    0·
    2 months ago

    Interesting running it in QEMU. If possible, it might be better to use a container if the host kernel supports this because performance and resource consumption should both be significantly improved.

    However, an emulator provides great flexibility I’ll give you that.

    • Possibly linux@lemmy.zipOPEnglish
      0·
      2 months ago

      I find pretty cool that I can run a x86_64 VM on my phone. Remember it is full machine so I can run actual containers.

      • henfredemars@infosec.pubEnglish
        0·
        2 months ago

        It is pretty cool! QEMU can do all kinds of interesting things, although I do wish it had better performance. High performance doesn’t appear to be a primary goal for QEMU outside of using KVM.

        • Possibly linux@lemmy.zipOPEnglish
          0·
          2 months ago

          You need hardware acceleration for any ki.d of performance. Without it you are just emulating which means you needs lots of hardware instructions for a few emulator instructions

          • henfredemars@infosec.pubEnglish
            0·
            2 months ago

            Yes indeed. I develop QEMU at work mainly implementation of new hardware as needed for my employer. It has a software emulator, but it’s not very good. It’s acceptable.

            The instruction generation backend does not seem to prioritize performance. Instead, it prioritizes accuracy and ease of maintenance. There is low-hanging fruit for making it faster but there isn’t much interest in doing so for the TCG backend. The attitude seems to be that it’s good enough.

            For a small example, you may find it interesting that QEMU does not implement floating point acceleration. It’s done in software even though the host has floating point instructions. It usually doesn’t attempt to use those floating point hardware facilities on the host and instead execute many hundreds of instructions to do floating point using the Berkeley software implementation. Almost never does this matter but it costs a lot of performance. Compare this to the translation performed by projects like FEX and Box64 which do and blow QEMU out of the water for specific use cases.

            Another place in the emulator that could be improved is handling of executable pages or cached output of the backend code generator. The executable code caching mechanism is very simple and could probably be much more aggressive on today’s systems.

            If you examine change logs, TCG really doesn’t get much TLC last time I checked. It could be a better emulator but performance outside of KVM use case is not as important to the project.

            • Possibly linux@lemmy.zipOPEnglish
              0·
              2 months ago

              Is there a faster emulator? From my experience qemu is pretty performant. It is especially fast when you use KVM or Hyper-V acceleration

              • henfredemars@infosec.pubEnglish
                0·
                2 months ago

                With KVM performance will be quite good, but when you need to emulate cross architecture? I don’t think there are many alternatives that support the entire VM. I only know of user space tools that are focused on emulating a binary.

            • Alex@lemmy.ml
              0·
              2 months ago

              QEMU absolutely will use hardware floating point where it can but only when it will give the correct results. FEX and Box64 are user mode emulators which achieve their speed by avoiding emulation where they can buy thunking at API boundaries.

              • henfredemars@infosec.pubEnglish
                0·
                2 months ago

                Call it a difference of opinion that I don’t believe it should try to be bit-accurate for floating point. But, it’s a valid position to take. There are many use cases for QEMU. In this case where we emit some host instructions I do believe it’s still within the helper function instead of inline which is not ideal. The guest code using floating point in the first place to me implies some degree of inaccuracy is permissible and this is the position that some cross architecture game emulators take. But again, I suppose it can depend what code you wish to run.

                • Alex@lemmy.ml
                  0·
                  2 months ago

                  QEMU is always going to focus on emulation fidelity first and there are few shortcuts. With floating point the differences aren’t generally in the numbers but in how the NaNs and other edge cases are handled. If you want to execute FP heavy code you should be cross compiling anyway.

  • drwankingstein@lemmy.dbzer0.comEnglish
    0·
    2 months ago

    for the semantically inquisitive folk.

    It’s worth noting if you are using this on an arm device, this isn’t a “virtualization VM” any more, as you are using the emulator backend, so this is far closer to a traditional emulator then anything else.

    While the term virtual machine is extremely poorly defined, it could still apply.

    also TCG is as slow as molasses, it’s a good demo, not actually usable for much, at least unless it’s a super beefy phone.

    • Possibly linux@lemmy.zipOPEnglish
      0·
      2 months ago

      I might switch to aarch64 to see if it is faster. However, you are right about the slowness. It isn’t bad but it is slow.

    • RegalPotoo@lemmy.worldEnglish
      0·
      2 months ago

      Looks like it’s an x86_64 kernel though? So this is a VM - it’s not running as a paravirtualised system, it’s having to emulate everything from the CPU up?

  • data1701d (He/Him)@startrek.websiteEnglish
    0·
    2 months ago

    I imagine it runs much more nicely than UTM SE on iOS. I was never able to get UTM JIT to work.

    Honestly, I want to jump ship from Apple, but I’m not in a position to do so at this time.

    • Possibly linux@lemmy.zipOPEnglish
      0·
      2 months ago

      A locked down ecosystem is not exactly good for hacking. Apple aggressively blocks outside software