qemu-system-aarch64: ZVM hangs after 6-7 minutes of normal operation on rk3588

[zijunWill]

Hello,

I am running ZVM on the rk3588 QEMU model according to the document https://github.com/processmission/qemu/blob/devel/docs/system/arm/rk3588.rst.

The ZVM image was successfully started, but after running normally for 6 to 7 minutes, QEMU completely lost response (crashed/frozen). The QEMU terminal showed no reaction, and I could only terminate the QEMU process from another terminal.

Tested images (all having the same issue):

• ZVM-RK3588v2.0
• ZVM-RK3588v2.1

Environment:

• QEMU branch: devel
• Host operating system: Ubuntu 22.04

QEMU log (attached):
qemu.log

If necessary, I would be more than happy to provide additional debugging information. Any suggestions would be greatly appreciated.

[zevorn]

Thanks for the report. I inspected the attached qemu.log and ran two controlled tests beyond the reported 6-7 minute failure window.

What the attached log shows

The attachment contains 313 lines:

• three startup reset dumps for each of the eight CPUs
• one dwmac4: write to unimplemented register at address: 0xdc message

The same startup reset count occurs in successful runs, and the same DWMAC warning has appeared in a passing RK3588 ZVM smoke test. The file contains no timestamps or state captured at the reported hang, so it is not sufficient to identify a DWMAC failure, a QEMU main-loop deadlock, a guest-side stall, or an idle/multiplexed console.

Controlled runs

The RK3588-related source files used for these runs are identical to devel at 90ff5899729ac1ec8006556731194a203abcc48b. QEMU was built for aarch64-softmmu and run under TCG without -icount.

1. The checked-in minimal ZVM fixture reached Start VM Successful! and created Zephyr VM0.
2. A complete image assembled from the hash-verified official ZVM RK3588 v2.0 kernel and filesystem archives reached:
   • Linux FS Image Loaded !
   • Start VM Successful!
   • [CREATE] linux VM 1 created and running

Both tests used rk3588s-roc-pc, 8 CPUs, 1 GiB RAM, if=sd,index=2, and the complete v2.0 run attached both gmac0 and gmac1. At 510 seconds, QMP still returned status=running and enumerated all eight vCPUs. QEMU was then terminated intentionally and exited cleanly.

This does not prove that your failure is invalid, but it means a deterministic 6-7 minute freeze is not currently reproduced with the verified v2.0 artifacts.

Information needed for an exact reproduction

Could you provide a complete, immutable build and image provenance record?

• exact QEMU commit (git rev-parse HEAD), configure command, and full QEMU command line
• host CPU architecture, compiler version, and whether the accelerator is TCG or KVM
• exact ZVM release download URL/version and SHA256 of every downloaded archive
• SHA256 of the final raw image passed to QEMU
• whether the image was freshly assembled/copied for the run or reused after previous boots
• exact image-building script/repository and commit
• exact official SDK repository URLs, branches, and commits used
• exact U-Boot repository and commit
• exact rkbin/TF-A/BL31/TPL/DDR firmware repositories, commits, blob versions, filenames, and SHA256 hashes
• exact Linux kernel repository/commit/config and root filesystem/module versions
• partition table, absolute sector offsets, and complete image assembly commands
• complete serial console log, kept separate from the QEMU -d debug log

Please also confirm that the ROC-PC run uses:

-machine rk3588s-roc-pc
-drive if=sd,index=2,file=<fresh-image>,format=raw
-nic user,model=gmac0
-nic user,model=gmac1

After Linux VM1 is created, the Linux guest console is not displayed automatically. From the ZVM shell, use:

zvm look 1

If using -serial mon:stdio, Ctrl-a c switches between the serial console and QEMU monitor.

Capture state at the actual hang

Please add a separate QMP socket:

-qmp unix:/tmp/rk3588.qmp,server=on,wait=off

At the alleged hang:

printf 'query-status\nquery-cpus-fast\n' | \
    build/run qmp-shell /tmp/rk3588.qmp

If QMP responds, the QEMU main loop is alive and we should next inspect guest/vCPU state and console routing. If QMP does not respond, please attach GDB to the host QEMU process and capture all thread stacks:

sudo gdb -q -batch -p "$QEMU_PID" \
    -ex 'set pagination off' \
    -ex 'thread apply all bt full'

The exact v2.1 image has not yet been validated here because it is distributed separately. Its archive URLs, hashes, build inputs, and final image hash are particularly important.

[zijunWill]

感谢您的回复。

u-boot-rockchip.bin 的完整构建流程

以下是我生成 u-boot-rockchip.bin 的全过程，麻烦你帮我看一下流程是否正确。

宿主机环境

• Ubuntu 22.04.5
• GCC 11.4（Ubuntu 11.4.0-1ubuntu1~22.04.3）、Python 3.10、DTC 1.6、SWIG 4

依赖安装：

sudo -E apt-get install -y --no-install-recommends \
    bc bison build-essential ca-certificates device-tree-compiler flex \
    gcc-aarch64-linux-gnu git libgnutls28-dev libssl-dev make patch \
    python3 python3-dev python3-pyelftools python3-setuptools swig

从 QEMU PR #2 仓库获取构建脚本和补丁

编译 u-boot-rockchip.bin 所需的构建脚本和 DTS 补丁在 QEMU 仓库的 roms/zvm-rk3588s-roc-pc/ 目录下。因为我的 Docker 网络太慢，无法在 Docker 内构建，所以我单独克隆了一份 QEMU 源码来获取这些脚本（这个仓库只用于构建 u-boot，不是用来编译 QEMU 模拟器的）：

mkdir -p "$HOME/src"
cd "$HOME/src"
git clone https://github.com/processmission/qemu.git qemu-pr2
cd qemu-pr2
git fetch origin pull/2/head:pr-2
git switch pr-2

确认构建所需的文件都存在：

test -f roms/zvm-rk3588s-roc-pc/Dockerfile
test -f roms/zvm-rk3588s-roc-pc/build-u-boot-rockchip.sh
test -f roms/zvm-rk3588s-roc-pc/u-boot-rk3588s-roc-pc-zvmcompat.diff

注意：这里用的是 PR #2 分支，因为只有这个分支的 roms/zvm-rk3588s-roc-pc/ 目录下才有 build-u-boot-rockchip.sh 构建脚本。

执行原生构建

我没有用 Docker。 因为 Docker 的网络下载太慢，所以我用了 --native 参数在宿主机上直接构建：

cd "$HOME/src/qemu-pr2"
chmod +x roms/zvm-rk3588s-roc-pc/build-u-boot-rockchip.sh

roms/zvm-rk3588s-roc-pc/build-u-boot-rockchip.sh \
    --native \
    --output-dir "$PWD/out/u-boot-rk3588s-native"

--native 参数会完全跳过 Docker 容器。构建脚本的流程是：

1. 通过宿主机的 Git 和当前代理，自动下载固定版本的 U-Boot 源码和 rkbin 固件
2. 应用 u-boot-rk3588s-roc-pc-zvmcompat.diff 补丁（DTS 兼容性补丁）
3. 使用宿主机安装的 aarch64-linux-gnu-gcc 交叉编译器编译 U-Boot
4. 使用固定时间戳重新打包 FIT 和 binman
5. 在步骤 5 校验最终 u-boot-rockchip.bin 的 SHA256

构建产物

out/u-boot-rk3588s-native/u-boot-rockchip.bin
out/u-boot-rk3588s-native/u-boot.bin
out/u-boot-rk3588s-native/idbloader.img
out/u-boot-rk3588s-native/u-boot.itb

SHA256 校验结果

u-boot-rockchip.bin SHA256: a1cb93daf9ae6abdaa43666c6c80460cb9994b2252932a808bc544e3f35109bd

构建脚本里记录的预期值是 6cd4b3...。不过我是在 Ubuntu 22.04 宿主机上本机构建的，而 Docker 用的是 Ubuntu 24.04，编译器版本不同，SHA256 不一样是正常的。

也就是说，现在所有文件里唯一可能跟你环境不同的就是 u-boot-rockchip.bin。可以请你分享一份你验证通过的 u-boot-rockchip.bin 给我吗？ 我只替换这一个文件，就能确认问题是否与 bin 构建差异有关。

---

串口卡死现象的完整复现

QEMU 版本与编译

git clone -b devel https://github.com/processmission/qemu.git ~/zvm_20/qemu
cd ~/zvm_20/qemu
./configure --target-list=aarch64-softmmu --enable-slirp
ninja -C build

• 加速器: TCG（无 KVM、无 -icount）

镜像制作

使用 ZVM-RK3588v2.0 release 中的 rk3588s-roc-pc-make-zvm-image.sh 脚本生成 TF 卡镜像。每次测试前都会先 rm -f 旧镜像、再重新生成，确保镜像全新。

QEMU 命令行

build/qemu-system-aarch64 \
  -accel tcg \
  -machine rk3588s-roc-pc \
  -smp 8 \
  -m 1G \
  -drive if=sd,index=2,file=zvm-rk3588-roc-master.img,format=raw \
  -nic user,model=gmac0 \
  -nic user,model=gmac1 \
  -serial mon:stdio \
  -display none \
  -qmp unix:/tmp/rk3588.qmp,server=on,wait=off

复现步骤

1. 执行上述 QEMU 命令启动
2. U-Boot 加载 ZVM 成功，ZVM 初始化全部通过，日志输出正常
3. ZVM 自启动创建 Zephyr VM0 和 Linux VM1，执行zvm look 1，Linux 登录提示符出现（rockchip-rk3588 login:）
4. 不对 QEMU 做任何操作，只是空等
5. 运行一段时间后，串口终端完全无响应：敲键盘无回显
6. Ctrl+A c 可以切换到 QEMU monitor，但再切回串口（serial0）显示为空白
7. QEMU 进程没有崩溃，显示 CPU 占用仍在

这个现象在每次使用全新镜像后都能稳定复现。不跑 cyclictest、不登录、不进行任何操作，单纯空等一样会挂死。

---

卡死时从外部采集的原始数据

以下数据仅通过 QMP 和 GDB 从 QEMU 外部采集，未做任何改动。

QMP query-status

{"return": {"status": "running", "running": true}}

QMP info registers -a

CPU#0:
  PC=0x1009f124    X00=0xfe690200
  PSTATE=0x800003c9  N--- NS EL2h    FPU disabled
  X05~X18 = 0xaaaaaaaa

CPU#1:
  PC=0x10039604    X00=0x00000004
  PSTATE=0x800003c9  N--- NS EL2h    FPU disabled
  X05~X18 = 0xaaaaaaaa

CPU#2:
  PC=0x1009f124    X00=0xfe6d0200
  PSTATE=0x800003c9  N--- NS EL2h    FPU disabled
  X05~X18 部分为 0xaaaaaaaa

CPU#3~#7:
  PC=0x1004fd98    X30=0x100b47f4
  PSTATE=0x200003c9  --C- NS EL2h    FPU disabled
  全部在 WFE

GDB 线程堆栈（QEMU 进程）

Thread 1  (main loop)    → ppoll waiting
Thread 3  (IO iothread)  → poll waiting
Thread 4  (CPU 0)        → cpu_exec/tb_lookup
Thread 5~11 (CPU 1~7)    → qemu_cond_wait

---

附件： qmp-dump.txt（QMP 完整诊断会话）、gdb-bt.txt（GDB 线程堆栈完整内容）随帖附上。

qmp-dump.txt

gdb-bt.txt

想请你帮忙的事情

1. 可以分享你验证通过的 u-boot-rockchip.bin 吗？ 或许用你的U-boot文件替换测试，排除构建差异这个变量，能够帮助我快速排查该问题。

[zevorn]

感谢您的回复。

u-boot-rockchip.bin 的完整构建流程

以下是我生成 u-boot-rockchip.bin 的全过程，麻烦你帮我看一下流程是否正确。

宿主机环境

• Ubuntu 22.04.5
• GCC 11.4（Ubuntu 11.4.0-1ubuntu1~22.04.3）、Python 3.10、DTC 1.6、SWIG 4

依赖安装：

sudo -E apt-get install -y --no-install-recommends
bc bison build-essential ca-certificates device-tree-compiler flex
gcc-aarch64-linux-gnu git libgnutls28-dev libssl-dev make patch
python3 python3-dev python3-pyelftools python3-setuptools swig

从 QEMU PR #2 仓库获取构建脚本和补丁

编译 u-boot-rockchip.bin 所需的构建脚本和 DTS 补丁在 QEMU 仓库的 roms/zvm-rk3588s-roc-pc/ 目录下。因为我的 Docker 网络太慢，无法在 Docker 内构建，所以我单独克隆了一份 QEMU 源码来获取这些脚本（这个仓库只用于构建 u-boot，不是用来编译 QEMU 模拟器的）：

mkdir -p "$HOME/src"
cd "$HOME/src"
git clone https://github.com/processmission/qemu.git qemu-pr2
cd qemu-pr2
git fetch origin pull/2/head:pr-2
git switch pr-2
确认构建所需的文件都存在：

test -f roms/zvm-rk3588s-roc-pc/Dockerfile
test -f roms/zvm-rk3588s-roc-pc/build-u-boot-rockchip.sh
test -f roms/zvm-rk3588s-roc-pc/u-boot-rk3588s-roc-pc-zvmcompat.diff

注意：这里用的是 PR #2 分支，因为只有这个分支的 roms/zvm-rk3588s-roc-pc/ 目录下才有 build-u-boot-rockchip.sh 构建脚本。

执行原生构建

我没有用 Docker。 因为 Docker 的网络下载太慢，所以我用了 --native 参数在宿主机上直接构建：

cd "$HOME/src/qemu-pr2"
chmod +x roms/zvm-rk3588s-roc-pc/build-u-boot-rockchip.sh

roms/zvm-rk3588s-roc-pc/build-u-boot-rockchip.sh
--native
--output-dir "$PWD/out/u-boot-rk3588s-native"
--native 参数会完全跳过 Docker 容器。构建脚本的流程是：

1. 通过宿主机的 Git 和当前代理，自动下载固定版本的 U-Boot 源码和 rkbin 固件
2. 应用 u-boot-rk3588s-roc-pc-zvmcompat.diff 补丁（DTS 兼容性补丁）
3. 使用宿主机安装的 aarch64-linux-gnu-gcc 交叉编译器编译 U-Boot
4. 使用固定时间戳重新打包 FIT 和 binman
5. 在步骤 5 校验最终 u-boot-rockchip.bin 的 SHA256

构建产物

out/u-boot-rk3588s-native/u-boot-rockchip.bin
out/u-boot-rk3588s-native/u-boot.bin
out/u-boot-rk3588s-native/idbloader.img
out/u-boot-rk3588s-native/u-boot.itb

SHA256 校验结果

u-boot-rockchip.bin SHA256: a1cb93daf9ae6abdaa43666c6c80460cb9994b2252932a808bc544e3f35109bd

构建脚本里记录的预期值是 6cd4b3...。不过我是在 Ubuntu 22.04 宿主机上本机构建的，而 Docker 用的是 Ubuntu 24.04，编译器版本不同，SHA256 不一样是正常的。

也就是说，现在所有文件里唯一可能跟你环境不同的就是 u-boot-rockchip.bin。可以请你分享一份你验证通过的 u-boot-rockchip.bin 给我吗？ 我只替换这一个文件，就能确认问题是否与 bin 构建差异有关。

串口卡死现象的完整复现

QEMU 版本与编译

git clone -b devel https://github.com/processmission/qemu.git ~/zvm_20/qemu
cd ~/zvm_20/qemu
./configure --target-list=aarch64-softmmu --enable-slirp
ninja -C build

• 加速器: TCG（无 KVM、无 -icount）

镜像制作

使用 ZVM-RK3588v2.0 release 中的 rk3588s-roc-pc-make-zvm-image.sh 脚本生成 TF 卡镜像。每次测试前都会先 rm -f 旧镜像、再重新生成，确保镜像全新。

QEMU 命令行

build/qemu-system-aarch64
-accel tcg
-machine rk3588s-roc-pc
-smp 8
-m 1G
-drive if=sd,index=2,file=zvm-rk3588-roc-master.img,format=raw
-nic user,model=gmac0
-nic user,model=gmac1
-serial mon:stdio
-display none
-qmp unix:/tmp/rk3588.qmp,server=on,wait=off

复现步骤

1. 执行上述 QEMU 命令启动
2. U-Boot 加载 ZVM 成功，ZVM 初始化全部通过，日志输出正常
3. ZVM 自启动创建 Zephyr VM0 和 Linux VM1，执行zvm look 1，Linux 登录提示符出现（rockchip-rk3588 login:）
4. 不对 QEMU 做任何操作，只是空等
5. 运行一段时间后，串口终端完全无响应：敲键盘无回显
6. Ctrl+A c 可以切换到 QEMU monitor，但再切回串口（serial0）显示为空白
7. QEMU 进程没有崩溃，显示 CPU 占用仍在

这个现象在每次使用全新镜像后都能稳定复现。不跑 cyclictest、不登录、不进行任何操作，单纯空等一样会挂死。

卡死时从外部采集的原始数据

以下数据仅通过 QMP 和 GDB 从 QEMU 外部采集，未做任何改动。

QMP query-status

{"return": {"status": "running", "running": true}}

QMP info registers -a

CPU#0:
  PC=0x1009f124    X00=0xfe690200
  PSTATE=0x800003c9  N--- NS EL2h    FPU disabled
  X05~X18 = 0xaaaaaaaa

CPU#1:
  PC=0x10039604    X00=0x00000004
  PSTATE=0x800003c9  N--- NS EL2h    FPU disabled
  X05~X18 = 0xaaaaaaaa

CPU#2:
  PC=0x1009f124    X00=0xfe6d0200
  PSTATE=0x800003c9  N--- NS EL2h    FPU disabled
  X05~X18 部分为 0xaaaaaaaa

CPU#3~#7:
  PC=0x1004fd98    X30=0x100b47f4
  PSTATE=0x200003c9  --C- NS EL2h    FPU disabled
  全部在 WFE

GDB 线程堆栈（QEMU 进程）

Thread 1  (main loop)    → ppoll waiting
Thread 3  (IO iothread)  → poll waiting
Thread 4  (CPU 0)        → cpu_exec/tb_lookup
Thread 5~11 (CPU 1~7)    → qemu_cond_wait

附件： qmp-dump.txt（QMP 完整诊断会话）、gdb-bt.txt（GDB 线程堆栈完整内容）随帖附上。

qmp-dump.txt

gdb-bt.txt

想请你帮忙的事情

1. 可以分享你验证通过的 u-boot-rockchip.bin 吗？ 或许用你的U-boot文件替换测试，排除构建差异这个变量，能够帮助我快速排查该问题。

see https://github.com/processmission/qemu/tree/devel/roms/zvm-rk3588s-roc-pc

[zijunWill]

感谢答复，关于之前 issue 中描述的卡死问题，我做了 6 组系统测试，所有测试均使用 zvm-rk3588-roc-master.img，进入 ZVM 后执行 zvm look 1。

测试结果汇总

#	-nic	内存	Serial	Monitor	空闲卡死	net操作后卡死	Ctrl+C 可退出
1	（默认）	2G	stdio	none	❌	-	✅
2	none	2G	stdio	none	✅ 正常	❌	✅
3	gmac0+gmac1	1G	stdio	none	❌	-	✅
4	gmac0	1G	stdio	none	✅ 正常	❌	✅
5	gmac0+gmac1	2G	stdio	none	❌	-	✅
6	gmac0	1G	mon:stdio	默认	✅ 正常	❌	❌ 完全无响应

测试指令：

指令1 — 卡死（不写 -nic，默认 NIC）：

build/qemu-system-aarch64 \
    -accel tcg \
    -machine rk3588s-roc-pc \
    -smp 8 \
    -m 2G \
    -drive if=sd,index=2,file=/path/to/zvm-rk3588-roc-master.img,format=raw \
    -serial stdio \
    -display none \
    -monitor none

指令2 — 空闲正常，执行 ip addr add + ip link set eth0 up 后立即卡死（-nic none）：

build/qemu-system-aarch64 \
    -accel tcg \
    -machine rk3588s-roc-pc \
    -smp 8 \
    -m 2G \
    -drive if=sd,index=2,file=/path/to/zvm-rk3588-roc-master.img,format=raw \
    -nic none \
    -serial stdio \
    -display none \
    -monitor none

指令3 — 卡死（双网卡）：

build/qemu-system-aarch64 \
    -accel tcg \
    -machine rk3588s-roc-pc \
    -smp 8 \
    -m 1G \
    -drive if=sd,index=2,file=/path/to/zvm-rk3588-roc-master.img,format=raw \
    -nic user,model=gmac0 \
    -nic user,model=gmac1 \
    -serial stdio \
    -display none \
    -monitor none

指令4 — 空闲正常，执行 ip addr add + ip link set eth0 up 后立即卡死（单网卡）：

build/qemu-system-aarch64 \
    -accel tcg \
    -machine rk3588s-roc-pc \
    -smp 8 \
    -m 1G \
    -drive if=sd,index=2,file=/path/to/zvm-rk3588-roc-master.img,format=raw \
    -nic user,model=gmac0 \
    -serial stdio \
    -display none \
    -monitor none

指令5 — 卡死（双网卡 + 2G）：

build/qemu-system-aarch64 \
    -accel tcg \
    -machine rk3588s-roc-pc \
    -smp 8 \
    -m 2G \
    -drive if=sd,index=2,file=/path/to/zvm-rk3588-roc-master.img,format=raw \
    -nic user,model=gmac0 \
    -nic user,model=gmac1 \
    -serial stdio \
    -display none \
    -monitor none

指令6 — 空闲正常，执行 net 操作后卡死且 Ctrl+C/A/X 均无效（单网卡 + -serial mon:stdio）：

build/qemu-system-aarch64 \
    -accel tcg \
    -machine rk3588s-roc-pc \
    -smp 8 \
    -m 1G \
    -drive if=sd,index=2,file=/path/to/zvm-rk3588-roc-master.img,format=raw \
    -nic user,model=gmac0 \
    -serial mon:stdio \
    -display none

结论

（1）以默认NIC或双网卡方式启动QEMU后，空闲状态下在10分钟内会出现卡死；

（2）使用nic none或单网卡 gmac0 方式启动QEMU时，空闲状态下正常，但只要在 guest 内执行 ip addr add + ip link set eth0 up 就会立即卡死；

（3）指令6 还暴露了 -serial mon:stdio + 默认 monitor 的问题：net 操作后不仅卡死，且所有 Ctrl 序列均无法退出，只能外部杀进程。

[zevorn]

Thanks for the detailed six-test matrix. The new results narrow this down to the DWMAC interrupt path rather than RAM size, TCG, or a QEMU main-loop deadlock.

I compared the current QEMU DWMAC4 model with the public ZVM/openEuler DWMAC driver and found a high-confidence root-cause candidate.

Likely failure sequence

1. On the first TX completion, QEMU sets TI | NIS in DMA_CHAN_STATUS at channel offset 0x1160. RX similarly sets RI | NIS.
2. dwmac4_update_irq() asserts the level IRQ whenever DMA_CHAN_STATUS & DMA_CHAN_INTR_ENA is non-zero.
3. However, the global DMA interrupt status register at DMA offset 0x1008 (DMA_STATUS in QEMU, DMA_IRQ_STATUS in the ZVM driver) is currently read-only and remains zero. The model never reflects the per-channel interrupt summary into this register.
4. The ZVM DWMAC ISR first reads DMA_IRQ_STATUS at 0x1008. It only calls the channel handler when DC0IS..DC7IS is set.
5. Because QEMU returns zero, ZVM never reads or W1C-clears DMA_CHn_STATUS at 0x1160.
6. The QEMU level IRQ therefore remains asserted indefinitely, producing an interrupt storm in ZVM/EL2. The guest console appears frozen while QEMU and QMP remain alive.

Relevant code:

• QEMU DWMAC model: https://github.com/processmission/qemu/blob/devel/hw/net/dwmac4.c
• Public ZVM DWMAC ISR: https://gitee.com/openeuler/zvm/blob/master/drivers/ethernet/eth_dwmac.c
• ZVM register definitions (DMA_IRQ_STATUS = 0x1008, channel bits, and DMA_CHn_STATUS): https://gitee.com/openeuler/zvm/blob/master/drivers/ethernet/eth_dwmac_priv.h

This also explains the full test matrix:

• ip link set eth0 up causes the first network activity and triggers the failure immediately.
• Default or dual-NIC configurations eventually generate background traffic, so the failure is delayed.
• Changing guest RAM does not affect it.
• QMP still reports running and the host QEMU threads are not deadlocked.
• The -serial mon:stdio behavior is most likely a symptom of the guest interrupt storm, not a separate monitor failure.

Proposed fix

The DWMAC model should maintain the global DMA interrupt summary before updating the IRQ line:

• Set global DMA_STATUS.DCnIS for each channel whose pending per-channel interrupt condition is contributing to the shared DMA IRQ.
• Recompute the global summary and IRQ whenever channel status changes, a W1C clear is performed, or DMA_CHAN_INTR_ENA changes.
• Keep DMA_STATUS read-only to the guest, but make it model-owned state rather than a permanent zero.
• Ensure reset and migration/post-load leave the summary register and IRQ level consistent.

The existing ax650x-pyramid/dwmac-40bit-dma-and-irq qtest checks the per-channel status and GIC pending bit, but does not read global offset 0x1008. The regression tests should additionally verify:

1. TX/RX completion sets the appropriate DCnIS bit at 0x1008.
2. W1C of DMA_CHn_STATUS clears the corresponding global summary bit and deasserts the IRQ.
3. Interrupt masking is reflected consistently.
4. Two DMA channels aggregate and clear independently.

The warning for the unimplemented register at 0xdc is not part of this failure chain; that register can be modeled separately.

Optional confirmation on the current binary

At the hang, the following QMP/HMP reads should provide a decisive confirmation for GMAC0:

{"execute":"human-monitor-command","arguments":{"command-line":"xp /1wx 0xfe1b1008"}}
{"execute":"human-monitor-command","arguments":{"command-line":"xp /1wx 0xfe1b1134"}}
{"execute":"human-monitor-command","arguments":{"command-line":"xp /1wx 0xfe1b1160"}}

The current buggy model is expected to show 0xfe1b1008 == 0 while 0xfe1b1160 still contains TI/RI + NIS and the matching bits are enabled at 0xfe1b1134. For GMAC1, use base 0xfe1c0000.

Until a model fix is available, the practical workaround is to keep the ZVM/Linux network interface down or disable the virtio-net-to-physical-GMAC path. -nic none alone is not sufficient if the guest later brings eth0 up.

This diagnosis is source-backed and matches all reported observations, but it should remain a high-confidence hypothesis until the register fix and focused qtest/runtime reproduction confirm it.