Lack of x86_64-v3 support in rosetta

[cfergeau]

Rosetta in linux guests currently (macOS 15) does not support the x86_64-v3 instruction set. This is going to be problematic for rhel10/centos10: https://developers.redhat.com/articles/2024/01/02/exploring-x86-64-v3-red-hat-enterprise-linux-10

For example, with podman on a M1 mac:

podman machine init
podman machine start
podman run -it --rm quay.io/centos/centos:stream10

This only prints Fatal glibc error: CPU does not support x86-64-v3

[cfergeau]

Nothing actionable for us, I'm filing this for documentation purpose.

[afbjorklund]

You can run AlmaLinux Kitten, which still offers both v2 and v3.

https://almalinux.org/blog/2024-10-22-introducing-almalinux-os-kitten/ ("older hardware" support)

EDIT: It would require a new image architecture built first though...

$ podman run -it --rm --platform linux/amd64/v2 docker.io/library/almalinux:10-kitten
...
WARNING: image platform (linux/amd64) does not match the expected platform (linux/amd64/v2)
Fatal glibc error: CPU does not support x86-64-v3

Unfortunately the images don't correctly specify their microarchitecture...

So they are putting v2 and v3 binaries, into an image labelled as v1 (or default amd64 variant)

Otherwise you get better errors, such as the ones you get on arm32.

[afbjorklund]

In case you were wondering, the el9 error when you ran v2 on v1 was very similar:

Fatal glibc error: CPU does not support x86-64-v2 (like if you run it with qemu64)

But Rosetta does support those SSE instructions, so only a problem with "too low" QEMU.

https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level

"We believe that x86-64-v2 is the appropriate choice for Red Hat Enterprise Linux 9." <-- still true for 10, with glibc-hwcaps

"The lack of emulation support could constrain developers targeting Red Hat Enterprise Linux 9." <-- we are here

"Even if we cannot show performance improvements for software included in RHEL <-- from the RHEL 10 blog post
it may still make sense to go ahead with the switch" <-- using AVX2 only matters for a very small number of packages

There was a similar "issue" with i386/i586/i686 before, and there a more conservative approach was taken for a long time.

[cfergeau]

Iirc, qemu/qemu@d135f781405f helps for x86_64-v2 and qemu.

[afbjorklund]

For Lima, reverting an "improvement" of cpuType worked too.

lima-vm/lima@c038c98

[dinvlad]

Just got bitten by the same, using

docker run --rm -it --pull always redhat/ubi10-minimal 
latest: Pulling from redhat/ubi10-minimal
Digest: sha256:653248684b69964d22876ab95ed379d1bda894c682fa6c058f26bd7e23cea232
Status: Image is up to date for redhat/ubi10-minimal:latest
Fatal glibc error: CPU does not support x86-64-v3

Any advice on how this could be handled?

[baude]

In the case of Podman machine, if we don't use Rosetta, but qemu instead, then it apparently works. You would have to test with something from main branch or deliberately change the provider to libkrun. In my case, I was running a dev version and using libkrun (implies no possibility of Rosetta).

$  $ podman run -it --rm --platform linux/amd64 quay.io/centos/centos:stream10 arch
Trying to pull quay.io/centos/centos:stream10...
Getting image source signatures
Copying blob sha256:909ab5d228a92689a64e8894dce20c71afbb2192604666573ce9435862e959ff
Copying config sha256:d934170861d08af2ff36b5df1397c3db9d98433dd7cea3fa9e4fb304a01ef02f
Writing manifest to image destination
x86_64

I realize this is a bit of a side step in the sense that it is a container and not a VM but probably food for thought.

[cfergeau]

This is fixed in macOS 26 beta.