On 08.10.2026 22:55, Aurelien Jarno wrote:
Source: qemu
Version: 1:11.1.2+ds-2
Severity: important
Tags: patch upstream
Control: found -1 1:10.0.11+ds-0+deb13u1
Dear Michael,
As you pointed out on IRC the qemu autopkgtest sometimes fail on riscv64:
| 717s === Checking if /usr/bin/qemu-arm64 can run executables:
| 717s glob with sh: /usr/bin/qemu-arm64 /bin/busybox ash -c "/usr/bin/qemu-arm64
/bin/busybox ls -dCFl debian/*[t]*":
| 717s /bin/busybox: line 0: can't open ash: no such file
| 717s Expected output not found
The full autopkgtest log is available here:
https://ci.debian.net/data/autopkgtest/testing/riscv64/q/qemu/76104339/log.gz
This happens on hosts with CPU which support vector extension. QEMU
detects it and use it. In this particular case, the RISCV-V vector
instructions are used, among other things, to emulate the aarch64 NEON
instructions.
I have found two issues in the TCG RISC-V backend that explain this
issue. I have submitted them upstream as patches:
-
https://lore.kernel.org/qemu-devel/[email protected]/
-
https://lore.kernel.org/qemu-devel/[email protected]/
I have tested that they fix the autopkgtest failure. Once accepted
upstream, could you please merge them (or a newer version if needed) in
the Debian package?
This is excellent news!
Let's do it sooner.
Note that the issue also affects the version in trixie, and as hardware
with vector instructions is becoming more common, we might also want to
fix it. The patch applies cleanly after adjusting the paths that got
changed as part of the 32-bit host support removal.
Adding
Cc: [email protected]
would do it. But I'll pick them up without that already.
Thank you!
/mjt
