"Illegal instruction" coredump running a Fedora VM on macOS

[billti]

I logged this issue at scipy/scipy#26098 and it was suggested to open an issue here.

Copying details below, but basically looks like the Linux aarch64 build doesn't handle running on Apple Silicon where the SVE instructions may not be available. (Not sure if this would apply to builds like Windows also which may run inside a VM on Apple CPUs).

Copied details

I'm using Parallels (v27.0.1) to run an aarch64 Fedora VM (Fedora 44 - uname -r reports "7.1.13-200.fc44.aarch64") on macOS. On loading scipy (version 1.18.1) I hit

Program terminated with signal SIGILL, Illegal instruction.
#0  0x0000ffff79c5d908 in init_parameter ()
   from /home/billti/demo/.venv/lib64/python3.14/site-packages/scipy/linalg/../../scipy.libs/libscipy_openblas-b7e2810b.so
[Current thread is 1 (Thread 0xffffa82af020 (LWP 15454))]

(gdb) x/i $pc
=> 0xffff79c5d908 <init_parameter+12>:	index	z2.s, #0, w8

Some back and forth with ChatGPT resulted in a brief description of:

On AArch64 Linux with HWCAP_SME present and HWCAP_SVE absent, SciPy’s bundled OpenBLAS 0.3.31.dev DYNAMIC_ARCH build selects Core: armv9sme. ARMV9SME is documented as requiring SVE+SME. Initialization executes index z2.s, #0, w8, an SVE instruction, causing SIGILL.

I would now separate responsibility this way:

• Fedora/Linux: looks correct. It exposes SME and no SVE.
• Parallels: may still influence CPU identification, but nothing you’ve shown so far proves it is advertising an invalid userspace capability.
• SciPy’s OpenBLAS wheel: does not include VORTEXM4.
• OpenBLAS runtime dispatch: appears to choose ARMV9SME despite SVE being absent, even though OpenBLAS itself defines that target as requiring SVE+SME. That is the clearest proximate bug.

Setting OPENBLAS_CORETYPE=ARMV8 avoids the crash, so it does appear to be a CPU features selection issue.

Running lscpu reports the Flags as below, which appears correct for Apple Silcon.

Flags:                   fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma 
                             lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2
                              frint bf16 bti afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 ebf16 s
                             me2 sme2p1 smei16i32 smebi32i32 smeb16b16 smef16f16

Reproducing Code Example

$ OPENBLAS_VERBOSE=2 python -c 'import scipy.linalg'

Error message

Falling back to generic ARMV8 core
Core: armv8
Core: armv9sme
Illegal instruction        (core dumped) OPENBLAS_VERBOSE=2 python -c 'import scipy.linalg'

SciPy/NumPy/Python version and system information

>>> import sys, scipy, numpy; print(scipy.__version__, numpy.__version__, sys.version_info); scipy.show_config()
1.18.1 2.3.5 sys.version_info(major=3, minor=14, micro=7, releaselevel='final', serial=0)
/home/billti/demo/.venv/lib64/python3.14/site-packages/scipy/__config__.py:167: UserWarning: Install `pyyaml` for better output
  warnings.warn("Install `pyyaml` for better output", stacklevel=1)
{
  "Compilers": {
    "c": {
      "name": "gcc",
      "linker": "ld.bfd",
      "version": "14.2.1",
      "commands": "cc"
    },
    "cython": {
      "name": "cython",
      "linker": "cython",
      "version": "3.2.9",
      "commands": "cython"
    },
    "c++": {
      "name": "gcc",
      "linker": "ld.bfd",
      "version": "14.2.1",
      "commands": "c++"
    },
    "fortran": {
      "name": "gcc",
      "linker": "ld.bfd",
      "version": "14.2.1",
      "commands": "gfortran"
    },
    "pythran": {
      "version": "0.19.0",
      "include directory": "../../../tmp/build-env-tnd5ov1o/lib/python3.14/site-packages/pythran"
    }
  },
  "Machine Information": {
    "host": {
      "cpu": "aarch64",
      "family": "aarch64",
      "endian": "little",
      "system": "linux"
    },
    "build": {
      "cpu": "aarch64",
      "family": "aarch64",
      "endian": "little",
      "system": "linux"
    },
    "cross-compiled": false
  },
  "Build Dependencies": {
    "blas": {
      "name": "scipy-openblas",
      "found": true,
      "version": "0.3.31.dev",
      "detection method": "pkgconfig",
      "include directory": "/opt/_internal/cpython-3.14.6/lib/python3.14/site-packages/scipy_openblas32/include",
      "lib directory": "/opt/_internal/cpython-3.14.6/lib/python3.14/site-packages/scipy_openblas32/lib",
      "openblas configuration": "OpenBLAS 0.3.31.dev DYNAMIC_ARCH NO_AFFINITY neoversev2 MAX_THREADS=64",
      "pc file directory": "/project/.openblas",
      "has ilp64": false,
      "cython blas ilp64": false
    },
    "lapack": {
      "name": "scipy-openblas",
      "found": true,
      "version": "0.3.31.dev",
      "detection method": "pkgconfig",
      "include directory": "/opt/_internal/cpython-3.14.6/lib/python3.14/site-packages/scipy_openblas32/include",
      "lib directory": "/opt/_internal/cpython-3.14.6/lib/python3.14/site-packages/scipy_openblas32/lib",
      "openblas configuration": "OpenBLAS 0.3.31.dev DYNAMIC_ARCH NO_AFFINITY neoversev2 MAX_THREADS=64",
      "pc file directory": "/project/.openblas",
      "has ilp64": false
    },
    "pybind11": {
      "name": "pybind11",
      "version": "3.0.4",
      "detection method": "config-tool",
      "include directory": "unknown"
    }
  },
  "Python Information": {
    "path": "/tmp/build-env-tnd5ov1o/bin/python",
    "version": "3.14"
  }
}

[billti]

Note: Running the below on the binary:

nm -D .venv/lib64/python3.14/site-packages/scipy.libs/libscipy_openblas-*.so |     grep -Ei 'VORTEXM4|ARMV9SME'

It shows lots of names suffixed with ARMV9SME, but none with VORTEXM4, so perhaps that binary doesn't include that CPU architecture?

[billti]

I see #5713 and #4715 which look like they might be related. As @martin-frbg worked on both of those, perhaps he knows the issue of the top of his head.

[martin-frbg]

That's a bit strange - if your (scipy's) build of the library doesn't have VORTEXM4 support (e.g. if it was built with gcc that doesn't support sme-without-sve), it should fall back to NEOVERSEN1 or ARMV8, certainly not ARMV9SME. (In the scipy show_config, it is reporting having autodetected neoversev2, which would also be an sve target - part of the autodetection is done via cpu part codes rather than capability flags. Does Parallels substitute its own cpu part number ?)
I guess your best bet is setting OPENBLAS_CORETYPE to NEOVERSEN1 - I'll try to take a look at the scipy-supplied libopenblas tomorrow

[billti]

Thanks! Note this issue came up in my searches, which is relevant but appears to be fixed in my Parallels version: https://forum.parallels.com/threads/parallels-26-1-1-incorrectly-reports-sve2-capability-in-arm-guest-on-apple-m4-pro.368736/

In my Linux VM I get the below reported:

AT_HWCAP:             0xefb3ffff
AT_HWCAP2:            0x7e13f924181

Which I believe means the bits for SVE and SVE2 are clear (i.e. not present) but set for SME and SME2 - which I believe is correct for Apple Silicon.

[martin-frbg]

So I think the problem is the unanticipated use of a Linux VM - the choice of cpu targets on an arm64 Mac is precisely - VORTEXM4 if HWCAP says SME present, VORTEX/NEOVERSEN1 if not. The same holds true for Linux, but only if the cpu implementer id matches Apple (0x61).
If Parallels reports its own hypervisor id in the cpu manufacturer field, the "mystery cpu" would end up in fallback code that would indeed assign ARMV9SME based on the SME hwcap, without checking for SVE as Apple is the only known (to me) exception that doesn't support both. What does /proc/cpuinfo return in your VM ?

[martin-frbg]

Found a Gentoo ticket (886484) that says Parallels uses the generic ARM Ltd implementer_id (0x41) - caught them out too.