I don't think that's right - containers are just userspace code, nothing to boot.

By my reading of TFA, your container runtime (eg Docker for Mac) should be able to provide an ARM VM, and use this Rosetta feature to run amd64 containers directly.

Containers that you and everyone else think of use Linux distros as a base, so yeah, anything else than Linux actually had to boot a VM to use them. That’s what eg Docker does on macOS.

Why does the rosetta binfmt_misc setup exclude starting amd64 containers? It's the same functionality the Docker desktop arm64 VM currently uses to run the process for an amd64 container via qemu (or any non arm64 container).

Docker on macOS already has some kind of qemu based solution for running x86_64 containers on m1.

Potentially this could be used as an alternative?

It's QEMU emulation. It's slow. It also segfaults a lot. I am able to run a select few containers on it, but I needed to sort out native arm64 for the vast majority.

The main reason for segfaults is that not all syscalls (syscalls on linux are different per architecture - not even 32bit and 64bit x86 use the same) are implemented in a 100% compatible way.

Yes, this is exactly what Apple has done - created Rosetta that handles Linux ELF binaries, translates code and syscalls.

Yes, Docker on macOS can switch from qemu-user to this. It uses the same binfmt mechanism, so it should be mostly a drop-in replacement.

This is only available in combination with Virtualization.framework, but Docker is already migrating from Hypervisor.framework to Virtualization.framework.

I have to admit to a little bit of trepidation about the Rosetta mount point. Will this work for Docker without explicitly passing that mount point through to the containers?

The way this would work is Docker would be setting this up for you (maybe through some option to switch between qemu and Rosetta).

The containers should not need the mount. What happens is Rosetta gets registered with the kernel (binfmt_misc) to execute x86 binaries. The is the same mechanism that allows seamless qemu support.

Yeah I'm not entirely sure how they're going to make this work, but I kind of understand why it's so weird, because there's really not any very good way to communicate between macOS userspace and some arbitrary kernel running inside the VM…