Running Intel Binaries in Linux VMs with Rosetta | Hacker News Reader

Running Intel Binaries in Linux VMs with Rosetta

developer.apple.com

This should be great when it gets integrated with Docker. And apparently that's high priority: https://github.com/docker/roadmap/issues/384

YMMV

I was excited for this because I thought it'd enable me to compile my HDL projects on my MacBook, since I'm targeting the Xilinx XC9500XL series of CPLDs this requires some an EOL design suite.

Anyway, build times are:

4 minutes with Rosetta 2

11 minutes with qemu-user-static

Whereas it only takes 20 seconds on my early 2013 MacBook Pro.

I think it would also be nice if it were possible to use this with other hypervisors. I believe it is limited to virtualization.framework so it cannot be used inside fusion for instance

Is it any faster the second time around? IIRC the first time it is translating the binaries as well as running the result.

I don't think so but I will double check tonight

Not faster the second time around, every time I run each command from the makefile it takes 1 minute before there is even any output too

I will try running things without involving docker and see if that changes anything

> 4 minutes with Rosetta 2

> 11 minutes with qemu-user-static

> Whereas it only takes 20 seconds on my early 2013 MacBook Pro.

This sounds suspicious to me. In my experience, Rosetta is faster on my M1 MBP than natively on my 2015 x86 MBP.

How did you measure this?

> This sounds suspicious to me. In my experience, Rosetta is faster on my M1 MBP than natively on my 2015 x86 MBP.

The performance will obviously depend on the workload

> How did you measure this?

Running the exact same docker image based on this: https://github.com/chriz2600/xilinx-ise And the code from this git repo of mine: https://github.com/LIV2/GottaGoFastRAM2000

Inside a Debian vm:

  docker run --rm -it -v ${PWD}:/build -w /build xilinx-ise /bin/bash

  cd RTL
  make clean
  time make ../Binary/XC9572XL/gottagofast2000.jed

When I get a chance I will check the timing of each individual step from the makefile.

If there is something I'm missing I'd love to know, I'd rather not have to run my builds on another machine

> Running the exact same docker image [...]

I don't think Docker supports using Rosetta to run x86 binaries inside arm64 containers. Here's an open feature request for it: https://github.com/docker/roadmap/issues/384

I'm not using docker desktop, I'm using docker inside a Debian VM.

I'm using an x86_64 container and it's definitely using Rosetta via binfmts because if I remove that the container won't even start

Rosetta is not limited to virtualization.framework. You can easily extract rosetta binaries and emulate stuff using qemu that Apple emulates if rosetta even checks something. I'm not sure if it would be legal, but technically it should not be a big issue. Apple just made it very easy with virtualization.framework.

Possibly dumb question - while running are you able to inspect the page mappings? If they’re doing runtime codegen (from the Rosetta pov that’s a jit no matter what), alternatively see if it appears heavy on x87.

The former means you lose a lot of the AOT benefits and caching in Rosetta, the latter is due to Rosetta implementing x87 precisely - so a ton of software floating point.

These are the two things that to me would be most likely to cause that degree of penalty.

Is there some information on how I can do that? I have no idea what I'm doing here lol

Lots of time is spent trying in mprotect syscalls that fail and return a segfault for some reason, screenshots in my tweet here: https://twitter.com/LIV2/status/1585565566525444099

I’ve had some good luck with this for light FPGA development with Vivado inside of a Debian VM. Performance is within 20-30% of my desktop which is more than fine to gain portability.

I’ve written up my experiences here: https://mremallin.ca/2022/10/24/xilinx-vivado-on-an-apple-m1...

Ah, that's awesome and just what I was looking for! Trying to do this sort of development on my Mac has been a nightmare ever since the move to apple silicon and so I'm happy to see that I can synthesize stuff locally again without needing to user a build server for everything...

Hi! I'm trying to follow your guide but when I try to install the amd64 packages, it gives a bunch of errors saying it can't locate any of the packages. I understand that the command you posted wasn't the original one that you used (and the original was lost) but any pointers in the right direction would be greatly appreciated!

This is nice, but unfortunately

> Rosetta doesn’t support the bootstrapping or installation of Intel Linux distributions on Mac computers with Apple silicon using the Virtualization framework.

So I guess it still won't be possible to run RHEL (or derivative) VMs on Apple Silicon. (Their aarch64 images don't work, something obscure with page size IIRC. Odd because Debian/Ubuntu's aarch64 work fine.)

Edit: Looks like RHEL9 has changed page size so it can run as a VM on Apple Silicon. Unfortunately my common use case for VMs is to prototype things for production, and that's all on RHEL7/8. :(

You install ARM linux on VM, you copy some binaries into that ARM linux which magically allow you to run x86 binaries inside that ARM linux. Those binaries will be translated using rosetta algorithms to arm machine code and run inside that ARM linux.

Fast emulating x86 VM probably is too hard for Rosetta so they decided not to even bother with it. I agree that it would make things much easier if one could just run x86 Linux with proper speed.

I assume both are against Apple's license terms but...

- Can you use Rosetta 2 without virtualization in Asahi?

- Can Rosetta 2 be used on something like an RPI/OrangePi?

Or is it somehow tied to the Apple virtualization via some kind of maigc?

There's some silly "DRM" that you need to bypass, but it should be able to run just fine in asahi after that.

I don't think a port to RPi/OrangePi is possible, as it relies on Apple Silicon being able to enter a strong memory ordering mode, necessary to emulate x86 without having to put memory fences everywhere. This likely relies on writing to MSRs that don't exist on the RPi, which will... either do nothing or crash it, but anyways won't do the right thing, which will probably lead to the app not working at all.

Here's a thread about this: https://twitter.com/marcan42/status/1534030476264218624?lang...

Reply on news.ycombinator.com