3 ms·

M1 doesn't have a special mode for Rosetta. All code is executed with x86 TSO on M1's application processors. How do I know this? Well, did you know Apple port

M1 doesn't have a special mode for Rosetta. All code is executed with x86 TSO on M1's application processors. How do I know this? Well, did you know Apple ported Rosetta 2 to Linux? You can get it by running a Linux VM on macOS. It does not require any kernel changes to support in VMs, and if you extract the binary to run it on Asahi Linux, it works just fine too. None of the Asahi team did anything to support x86 TSO. Rosetta also works just fine in m1n1's hypervisor mode, which exists specifically to log all hardware access to detect these sorts of things. If there is a hardware toggle for TSO, it's either part of the chicken bits (and thus enabled all the time anyway) or turned on by iBoot (and thus enabled before any user code runs). Related point: Hector Martin just upstreamed a patch to Linux that fixes a memory ordering bug in workqueues that's been around since before Linux had Git history. He also found a bug in some ARM litmus tests that he was using to validate whether or not they were implemented correctly. Both of those happened purely because M1 and M2 are so hilariously wide and speculative that they trigger memory reorders no other CPU would.

anyfoo 4y ago
> M1 doesn't have a special mode for Rosetta. All code is executed with x86 TSO on M1's application processors. That's not true. (And doesn't your last paragraph contradict it already?) You might just have figured out that most stuff will run fine (or appear to run fine for a long time) when TSO isn't enabled.
- messe 4y ago
  I have no idea why you are being downvoted. You are entirely correct.
  - anyfoo 4y ago
    Thanks, I was puzzled as well. The downvotes seem to have stopped, though.
messe 4y ago
I'm sorry, but please cite some sources, because this contradicts everything that's been said about M1's x86 emulation that I've read so far. > Well, did you know Apple ported Rosetta 2 to Linux? You can get it by running a Linux VM on macOS. It does not require any kernel changes to support in VMs, and if you extract the binary to run it on Asahi Linux, it works just fine too. None of the Asahi team did anything to support x86 TSO. Rosetta also works just fine in m1n1's hypervisor mode, which exists specifically to log all hardware access to detect these sorts of things. If there is a hardware toggle for TSO, it's either part of the chicken bits (and thus enabled all the time anyway) or turned on by iBoot (and thus enabled before any user code runs). Apple tells you to attach a special volume/FS to your linux VM in order for Rosetta to work. When such a volume is attached, it runs the VM in TSO mode. As simple as that. The rosetta binary itself doesn't know whether or not TSO is enabled, so its not surprising that it runs fine under Asahi. As marcan42 himself said on twitter[1], most x86 applications will run fine even without TSO enabled. You're liable to run into edge cases in heavily multithreaded code though. [1]: https://twitter.com/marcan42/status/1534054757421432833 https://twitter.com/marcan42/status/1534054757421432833 > Both of those happened purely because M1 and M2 are so hilariously wide and speculative that they trigger memory reorders no other CPU would. In other words, they're not constantly running in TSO mode? Because if they were, why would they trigger such re-orders? EDIT: I've just run a modified version of the following test program[2] (removing the references to the tso_enable sysctl which requires an extension), both native and under Rosetta. Running natively, it fails after ~3500 iterations. Under Rosetta, it completes the entire test successfully. [2] https://github.com/losfair/tsotest/ https://github.com/losfair/tsotest/
- kmeisthax 4y ago
  Hmm, wasn't aware that someone found a TSO sysctl that actually does something. The rest of my opinion is based off of these three Twitter threads: https://twitter.com/marcan42/status/1534053625110351872 https://twitter.com/marcan42/status/1534053625110351872 https://twitter.com/never_released/status/1534127641082593281 https://twitter.com/never_released/status/153412764108259328... https://twitter.com/marcan42/status/1534156788224098304 https://twitter.com/marcan42/status/1534156788224098304

anyfoo 4y ago

> M1 doesn't have a special mode for Rosetta. All code is executed with x86 TSO on M1's application processors. That's not true. (And doesn't your last paragraph contradict it already?) You might just have figured out that most stuff will run fine (or appear to run fine for a long time) when TSO isn't enabled.

messe 4y ago
I have no idea why you are being downvoted. You are entirely correct.
- anyfoo 4y ago
  Thanks, I was puzzled as well. The downvotes seem to have stopped, though.

messe 4y ago

I'm sorry, but please cite some sources, because this contradicts everything that's been said about M1's x86 emulation that I've read so far. > Well, did you know Apple ported Rosetta 2 to Linux? You can get it by running a Linux VM on macOS. It does not require any kernel changes to support in VMs, and if you extract the binary to run it on Asahi Linux, it works just fine too. None of the Asahi team did anything to support x86 TSO. Rosetta also works just fine in m1n1's hypervisor mode, which exists specifically to log all hardware access to detect these sorts of things. If there is a hardware toggle for TSO, it's either part of the chicken bits (and thus enabled all the time anyway) or turned on by iBoot (and thus enabled before any user code runs). Apple tells you to attach a special volume/FS to your linux VM in order for Rosetta to work. When such a volume is attached, it runs the VM in TSO mode. As simple as that. The rosetta binary itself doesn't know whether or not TSO is enabled, so its not surprising that it runs fine under Asahi. As marcan42 himself said on twitter[1], most x86 applications will run fine even without TSO enabled. You're liable to run into edge cases in heavily multithreaded code though. [1]: https://twitter.com/marcan42/status/1534054757421432833 https://twitter.com/marcan42/status/1534054757421432833 > Both of those happened purely because M1 and M2 are so hilariously wide and speculative that they trigger memory reorders no other CPU would. In other words, they're not constantly running in TSO mode? Because if they were, why would they trigger such re-orders? EDIT: I've just run a modified version of the following test program[2] (removing the references to the tso_enable sysctl which requires an extension), both native and under Rosetta. Running natively, it fails after ~3500 iterations. Under Rosetta, it completes the entire test successfully. [2] https://github.com/losfair/tsotest/ https://github.com/losfair/tsotest/

kmeisthax 4y ago
Hmm, wasn't aware that someone found a TSO sysctl that actually does something. The rest of my opinion is based off of these three Twitter threads: https://twitter.com/marcan42/status/1534053625110351872 https://twitter.com/marcan42/status/1534053625110351872 https://twitter.com/never_released/status/1534127641082593281 https://twitter.com/never_released/status/153412764108259328... https://twitter.com/marcan42/status/1534156788224098304 https://twitter.com/marcan42/status/1534156788224098304