QEMU crash in gen_pinsr (SIGABRT) when emulating x86_64 on Apple Silicon

**Describe the issue**
UTM crashes with SIGABRT inside qemu-x86_64-softmmu:

gen_pinsr → i386_tr_translate_insn → translator_loop

This appears to be a QEMU TCG assertion triggered during x86 instruction translation (likely PINSR-family instruction).

**Configuration**
* UTM Version: 4.7.5 (118)
* macOS Version: Sequoia 15.7.4
* Mac Chip (Intel, M1, ...): M4 Pro

**Crash log**

[qemu_crash_log.txt](https://github.com/user-attachments/files/28176965/qemu_crash_log.txt)

**Upload VM**

[config.plist.zip](https://github.com/user-attachments/files/28177360/config.plist.zip)

# UTM / QEMU Crash Log Analysis

## Executive Summary

The crash is in **UTM 4.7.5 (build 118)** while running the bundled **QEMU x86_64 system emulator** on an **Apple Silicon Mac (Mac16,7 / M4 Pro)**.

The failure is not a macOS networking driver crash and does not appear to be caused by `vmnet`, SPICE, OpenGL, or memory pressure. The decisive stack trace shows QEMU aborting internally while translating an x86 instruction:

```text
Exception Type: EXC_CRASH (SIGABRT)
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
Crashed Thread: 3
...
__assert_rtn
qemu-x86_64-softmmu gen_pinsr.cold.1
qemu-x86_64-softmmu gen_pinsr
i386_tr_translate_insn
translator_loop
x86_translate_code
tb_gen_code
cpu_exec_loop
mttcg_cpu_thread_fn
```

Most likely interpretation: **QEMU hit an internal assertion in its x86 instruction translator, specifically around generation of the `PINSR*` instruction family**, while emulating an x86_64 guest using TCG on ARM64.

This points to a **QEMU/UTM emulation bug or unsupported/incorrectly handled guest CPU instruction path**, rather than a guest OS bug in the ordinary sense.

---

## Environment Captured in the Log

| Field | Value |
| -------------------------------- | --------------------------------------- |
| Application | UTM / QEMULauncher |
| UTM Version | 4.7.5 build 118 |
| Crashed binary | `QEMULauncher` |
| Emulation binary | `qemu-x86_64-softmmu` |
| Host CPU architecture | ARM64 native |
| Host machine | Mac16,7, Apple M4 Pro |
| Host memory | 48 GB |
| macOS version | macOS 15.7.4 build 24G517 |
| Guest architecture implied | x86_64 system emulation |
| Crash time | 2026-05-23 05:50:45 -0400 |
| UTM process launch time | 2026-05-19 13:57:38 -0400 |
| Approximate runtime before crash | ~3 days 15 hours 53 minutes |
| System uptime | 660,000 seconds, approximately 7.6 days |
| SIP | Enabled |

---

## Primary Failure Signature

### Crash Classification

```text
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process: QEMULauncher [27442]
```

This is an **intentional abort**, not a segmentation fault or host access violation. The process called `abort()` after an internal assertion failed.

The key frames are:

```text
2 libsystem_c.dylib abort
3 libsystem_c.dylib __assert_rtn
4 qemu-x86_64-softmmu gen_pinsr.cold.1
5 qemu-x86_64-softmmu gen_pinsr
6 qemu-x86_64-softmmu i386_tr_translate_insn
7 qemu-x86_64-softmmu translator_loop
8 qemu-x86_64-softmmu x86_translate_code
9 qemu-x86_64-softmmu setjmp_gen_code
10 qemu-x86_64-softmmu tb_gen_code
11 qemu-x86_64-softmmu cpu_exec_loop
15 qemu-x86_64-softmmu mttcg_cpu_thread_fn
```

The crash occurred inside QEMU's **dynamic translation pipeline**, not in a device backend, UI layer, network stack, or macOS framework.

---

## What `gen_pinsr` Suggests

`gen_pinsr` is strongly suggestive of QEMU translating an x86 SIMD instruction in the `PINSR*` family, such as:

- `PINSRB`
- `PINSRW`
- `PINSRD`
- `PINSRQ`

These instructions insert a byte, word, doubleword, or quadword into an XMM register. They are associated with SSE/SSE4-era instruction handling.

The presence of:

```text
qemu-x86_64-softmmu gen_pinsr
qemu-x86_64-softmmu i386_tr_translate_insn
```

means QEMU was translating a guest x86 instruction and hit an assertion while generating the corresponding host-side translated block.

### Practical meaning

This usually means one of the following:

1. **QEMU encountered an instruction variant it did not expect for the currently configured virtual CPU model.**
2. **The guest executed an instruction path that exposes a QEMU translator bug.**
3. **The selected CPU feature set in the VM is inconsistent with what QEMU's translator expects.**
4. **A long-running translated-code edge case was triggered after days of runtime.**

Because the process aborts via `__assert_rtn`, this is more like an internal invariant failure than an external environmental problem.

---

## What the Crash Does _Not_ Look Like

### Not primarily a macOS `vmnet` crash

Thread 7 is in Apple's `vmnet` framework:

```text
Thread 7:: Dispatch queue: org.qemu.vmnet.if_queue
0 libsystem_kernel.dylib getsockopt
1 vmnet __vmnet_interface_set_event_callback_block_invoke_3
```

However, Thread 7 is **not the crashed thread**. It appears to be handling a normal network event callback. The actual crash is Thread 3 in QEMU's CPU translation/execution path.

So while networking may have been active, this crash log does not support the conclusion that `vmnet` caused the abort.

### Not primarily SPICE/display-related

Thread 5 is the SPICE worker:

```text
Thread 5:: SPICE Worker
...
spice-server.1 red_worker_main
```

It is waiting in the GLib main loop and is not the crashed thread.

### Not a host memory exhaustion signature

The VM region summary shows a large virtual address footprint:

```text
TOTAL 14.7G
VM_ALLOCATE 10.3G
MALLOC 3.1G
```

But resident/written memory is small in the crash summary, and the termination reason is `SIGABRT` from an assertion, not jetsam, memory pressure, or allocation failure.

### Not Rosetta translation

The log says:

```text
Code Type: ARM-64 (Native)
translated: false
```

UTM/QEMU is running natively as ARM64. The x86_64 part is the guest CPU being emulated by QEMU, not Rosetta translating the app.

---

## Why This Matters for UTM on Apple Silicon

The log shows:

```text
qemu-x86_64-softmmu.framework
```

That means this VM is using **x86_64 system emulation** on an ARM64 host. On Apple Silicon, this is materially different from running an ARM64 guest with hardware virtualization.

For x86_64 guests on Apple Silicon:

- CPU execution is handled by QEMU's TCG dynamic translator.
- Performance is significantly lower than native virtualization.
- Correctness depends on QEMU accurately translating every x86 instruction the guest executes.
- Bugs can appear only under specific guest workloads, CPU feature combinations, or long-running workloads.

This crash is consistent with a TCG translator assertion.

---

## Most Likely Root Cause

### High-confidence conclusion

The immediate root cause is:

> **QEMU aborted because an internal assertion failed while translating an x86 `PINSR*`-related instruction in the x86_64 TCG translator.**

### Likely broader cause

The broader cause is likely one of:

1. **A QEMU bug bundled with UTM 4.7.5.**
2. **A guest workload triggering a problematic x86 SIMD instruction translation path.**
3. **A VM CPU model / CPU feature configuration that advertises or enables a feature combination QEMU mishandles.**
4. **A regression in the UTM-bundled QEMU build.**

---

## Recommended Mitigations / Experiments

These are ordered from least invasive to most invasive.

### 1. Capture the exact VM configuration

Before changing anything, record:

- VM architecture: x86_64
- VM CPU model
- Number of CPU cores
- Whether hypervisor acceleration is enabled or unavailable
- Display device
- Network mode: shared, bridged, emulated VLAN, etc.
- QEMU arguments from UTM, if visible/exportable
- Guest OS version
- What the guest was doing near the time of crash

This will be important for a reproducible GitHub issue.

### 2. Try changing the virtual CPU model

Because the crash is in x86 instruction translation, CPU feature exposure is a prime suspect.

Recommended experiments:

- Switch from a host-like/default CPU model to a more conservative CPU model if UTM exposes that option.
- Disable advanced CPU features if UTM allows custom QEMU arguments.
- Try reducing exposed SIMD feature levels if configurable.

The goal is to avoid the exact instruction feature path that leads into the failing `gen_pinsr` assertion.

### 3. Reduce vCPU count temporarily

The crash occurred in:

```text
mttcg_cpu_thread_fn
```

`mttcg` is QEMU's multi-threaded TCG CPU execution path. Reducing vCPUs can sometimes avoid translator/concurrency edge cases or make repros more stable.

Recommended test:

- Temporarily reduce the VM to 1 vCPU.
- If stable, try 2 vCPUs.
- Compare against the previous vCPU count.

This is not a guaranteed fix, but it is a useful isolation step.

### 4. Update UTM / QEMU if a newer build is available

This crash is inside the bundled QEMU framework. If UTM has a newer release with a newer QEMU build, updating is one of the most likely practical fixes.

Current crashing version:

```text
UTM 4.7.5 build 118
qemu-x86_64-softmmu.framework
```

### 5. If possible, use an ARM64 guest instead of x86_64

If the workload permits it, replacing the x86_64 guest with an ARM64 guest avoids this entire class of x86_64 TCG translation failures.

This is usually the most robust approach on Apple Silicon, because ARM64 guests can use hardware virtualization paths rather than full x86 CPU emulation.

### 6. Disable or change nonessential devices only after CPU tests

The crash does not primarily implicate display, SPICE, networking, or USB. Still, if the crash persists, additional isolation steps are reasonable:

- Change display backend/device.
- Disable 3D acceleration if enabled.
- Change network mode away from `vmnet` temporarily.
- Remove unnecessary USB passthrough devices.
- Disable sound temporarily.

These are secondary because the crashing stack is CPU translation, not device emulation.

---