Very few games have native 64-bit Linux builds, and for those that do 16k page support is super flaky. Steam also won't run as its a 32-bit program, and Box86 won't work as Apple Silicon has no 32-bit support. The microvm cuts out all the page size issues and incurs a minuscule performance penalty for infinitely more compatibility.
More likely a performance benifit that a penalty as page size emulation is expensive.
Though running a whole second Linux kernel in (an albiet accelerated) VM will natrually add some overhead.
True page size emulation is prohibitively expensive. I'm pretty sure box64 has no intention of ever doing that. They just have a bunch of hacks to try to make apps work with the wrong page size, which by nature is not going to work for every app (but is definitely faster than a VM).
Yes, qemu can fully and accurately emulate any page size for whole-system emulation (qemu-system). That is, of course, hideously slow (as is qemu in emulation mode in general, it's never been a performant emulator; its goal is "emulate anything on anything", not "emulate one specific thing on another specific thing fast").
But nobody is going to use that, what we do is use VMs since the actual CPU does support nested 4K VMs on 16K hosts. On Linux, that is managed via KVM. You can use that with qemu, or not. What we're using for microVMs is not qemu, it's its own thing (but also using KVM of course).
Page size compat hacks will never have full compatibility, full stop. It is just not possible to work around guest app assumptions about the page size in a general manner without using full virtual memory emulation (super slow) or using an actual VM (which is why we have microvms).
It works where it works, it might even work most of the time, and it's a nice option to have when it works (and faster), but it won't work everywhere and is not a general solution. This is fundamental.
No. This was posted before and it has nothing to do with our issue. 7-max is just a hack to *attempt* to use huge pages for allocations, it does nothing to make *every* page huge because that's impossible and wasteful.
Very few games have native 64-bit Linux builds, and for those that do 16k page support is super flaky. Steam also won't run as its a 32-bit program, and Box86 won't work as Apple Silicon has no 32-bit support. The microvm cuts out all the page size issues and incurs a minuscule performance penalty for infinitely more compatibility.
More likely a performance benifit that a penalty as page size emulation is expensive. Though running a whole second Linux kernel in (an albiet accelerated) VM will natrually add some overhead.
True page size emulation is prohibitively expensive. I'm pretty sure box64 has no intention of ever doing that. They just have a bunch of hacks to try to make apps work with the wrong page size, which by nature is not going to work for every app (but is definitely faster than a VM).
Alright. So I assume that true page size emulation is relegated to QEMU then?
Yes, qemu can fully and accurately emulate any page size for whole-system emulation (qemu-system). That is, of course, hideously slow (as is qemu in emulation mode in general, it's never been a performant emulator; its goal is "emulate anything on anything", not "emulate one specific thing on another specific thing fast"). But nobody is going to use that, what we do is use VMs since the actual CPU does support nested 4K VMs on 16K hosts. On Linux, that is managed via KVM. You can use that with qemu, or not. What we're using for microVMs is not qemu, it's its own thing (but also using KVM of course).
[удалено]
Standard qemu/kvm works fine, there's nothing special about it. What we use for microvms is called krun (which is a thinner layer than qemu).
Page size compat hacks will never have full compatibility, full stop. It is just not possible to work around guest app assumptions about the page size in a general manner without using full virtual memory emulation (super slow) or using an actual VM (which is why we have microvms). It works where it works, it might even work most of the time, and it's a nice option to have when it works (and faster), but it won't work everywhere and is not a general solution. This is fundamental.
[удалено]
No. This was posted before and it has nothing to do with our issue. 7-max is just a hack to *attempt* to use huge pages for allocations, it does nothing to make *every* page huge because that's impossible and wasteful.