autopkgtest_qemu doesn't use accel=kvm on ppc64le, being fully unusable on that arch
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
autopkgtest (Debian) |
Fix Released
|
Unknown
|
|||
autopkgtest (Ubuntu) |
Fix Released
|
High
|
Paride Legovini | ||
Jammy |
Fix Released
|
High
|
Paride Legovini |
Bug Description
[ Impact ]
On Power9 the qemu based autopkgtest commands create VMs that are extremely slow and fail with obscure errors (partially discussed in LP: #1973628, comment 8). This can be reproduced for example by running:
autopkgtest-
but autopkgtest-
This happens because autopkgtest fails to detect the system architecture as KVM capable due to a typo in the architecture name (ppc64el instead of ppc64le). This upload fixes the typo.
Fixing this bug in Jammy will allow users and developers to manually run autopkgtests on ppc64el. This is useful for example in +1 maintenance.
[ Test Plan ]
Run:
autopkgtest-
on an affected system (= a KVM-capable POWER machine running Jammy).
Buggy package => the command takes hours to complete and prints lots of obscure errors.
Fixed package => the command completes in minutes.
[ Where problems could occur ]
Without this fix qemu based autopkgtest could in principle complete even when KVM is available (/dev/kvm exists) but broken, as it may be in some nested virtualization scenarios. This said, without KVM qemu based appears to be very broken due to timeouts caused by its extreme slowness, so I think the risk of causing a regression is marginal.
[ Other Info ]
The very same fix has been submitted and merged upstream, and released to Kinetic via a clean cherry-pick.
[ Original Description ]
On Power9 the qemu based autopkgtest commands create VMs that are extremely slow and fail with obscure errors (partially discussed in LP: #1973628, comment 8). This can be reproduced for example by running:
autopkgtest-
but autopkgtest-
With this change everything is very fast and reliable. These warnings also went away:
qemu-system-
qemu-system-
qemu-system-
qemu-system-
indicating that we were using TCG emulation before.
I imagine that Qemu has good reasons not to default to accel=kvm or accel=kvm:tcg on ppc64, but think it's reasonable to assume it's available and enable it in autopkgtest.
We can fix this in autopkgtest upstream, but it would be nice to verify if this is an issue with Debian too before submitting a salsa MR.
Related branches
- Brian Murray (community): Approve
- Canonical's Ubuntu QA: Pending requested
- git-ubuntu import: Pending requested
-
Diff: 41 lines (+10/-3)3 files modifieddebian/changelog (+7/-0)
debian/control (+2/-1)
lib/autopkgtest_qemu.py (+1/-2)
- Brian Murray (community): Approve
- git-ubuntu import: Pending requested
-
Diff: 41 lines (+10/-3)3 files modifieddebian/changelog (+7/-0)
debian/control (+2/-1)
lib/autopkgtest_qemu.py (+1/-2)
tags: | added: ppc64el |
Changed in autopkgtest (Debian): | |
status: | Unknown → Fix Committed |
Changed in autopkgtest (Ubuntu): | |
importance: | Undecided → High |
Changed in autopkgtest (Ubuntu Jammy): | |
importance: | Undecided → High |
Changed in autopkgtest (Ubuntu): | |
status: | New → Triaged |
Changed in autopkgtest (Ubuntu Jammy): | |
status: | New → Triaged |
Changed in autopkgtest (Ubuntu): | |
assignee: | nobody → Paride Legovini (paride) |
Changed in autopkgtest (Ubuntu Jammy): | |
assignee: | nobody → Paride Legovini (paride) |
Changed in autopkgtest (Ubuntu Jammy): | |
status: | Triaged → In Progress |
description: | updated |
description: | updated |
Changed in autopkgtest (Debian): | |
status: | Fix Committed → Fix Released |
We need Christian's Qemu insight on this one.
For the record this is the change I applied locally to force kvm usage:
--- /tmp/autopkgtes t_qemu. py.orig autopkgtest/ lib/autopkgtest _qemu.py
boot == 'efi'
argv. extend( ['-machine' , 'q35']) architecture == 'ppc64le': ['-machine' , 'accel=kvm'])
+++ /usr/share/
@@ -329,6 +329,8 @@
):
+ elif self.qemu_
+ argv.extend(
# Some architectures can only be run with certain CPUs
if '-cpu' not in qemu_options: