Public bug reported:
## Summary
KVM guests on an Ubuntu host with an Intel Core i5-14400 reproducibly
become unstable and eventually crash when using:
```xml
<cpu mode='host-passthrough' check='none' migratable='off'>
```
Changing only this setting to:
```xml
<cpu mode='host-passthrough' check='none' migratable='on'>
```
makes the same guests stable.
The failure has been reproduced with multiple independent VMs, different
guest kernel versions, without PCI passthrough, with one and multiple
vCPUs, and on different host CPU cores.
The typical failure is repeated segmentation faults of systemd/PID 1 and
other guest processes, followed by:
```text
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000008b
```
or a completely unresponsive guest while QEMU/libvirt still considers
the domain running.
This appears very similar to Fedora/Red Hat Bug 2448303:
"KVM guest will get kernel panic or freeze when migratable setting is off".
At the time of writing, an additional isolation test with
`migratable='off'` and only QEMU CPU feature `invtsc` disabled is still
running.
---
## Host
Distribution: Ubuntu
Architecture: x86_64
Host kernel:
```text
Linux Core 7.0.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Aug 1 04:26:38
UTC 2026 x86_64 GNU/Linux
```
CPU:
```text
Intel(R) Core(TM) i5-14400
family: 0x6
model: 0xb7
stepping: 0x1
```
CPU F/M/S:
```text
06-b7-01
```
Motherboard:
```text
ASUS PRIME Z690M-PLUS D4
```
BIOS:
```text
Version 4003
Date 2026-05-08
```
Intel microcode currently loaded:
```text
0x133
```
Ubuntu intel-microcode package:
```text
intel-microcode 3.20260210.1ubuntu2
```
The host itself remains stable while the guests fail. CPU/RAM stress
testing on the host did not reproduce errors.
XMP is enabled. This configuration has not been changed during the tests
described below.
---
## VM configuration
The problem was originally observed in a Q35/OVMF VM using host CPU
passthrough.
Relevant CPU configuration:
```xml
<cpu mode='host-passthrough' check='none' migratable='off'>
<topology sockets='1' dies='1' clusters='1' cores='2' threads='1'/>
<cache mode='passthrough'/>
</cpu>
```
Machine type:
```text
pc-q35-10.2
```
Firmware:
```text
OVMF / UEFI
```
The original VM also used PCI passthrough, but PCI passthrough was
subsequently removed completely and the failure remained reproducible.
Therefore PCI passthrough is not required to trigger the problem.
Test VMs use normal virtual storage/devices and otherwise reproduce the
same failure.
---
## Failure symptoms
Guests initially boot and operate normally.
After a variable amount of time, usually tens of minutes and sometimes
approximately 1-1.5 hours, systemd/PID 1 starts producing segmentation
faults.
Typical sequence:
```text
systemd[1]: segfault ...
```
followed eventually by:
```text
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000008b
```
Repeated segmentation faults have also been observed in libc/systemd-
related execution before the final panic.
The failure is not always a clean panic. In some runs the guest becomes
completely unresponsive:
* SSH times out
* VNC display freezes
* QEMU guest agent stops responding
* libvirt still reports the domain as "running"
* host remains responsive and stable
The timing is not deterministic.
Observed failures have occurred after roughly 20-95 minutes depending on
the test.
---
## Reproduction across independent VMs
To exclude corruption of the original guest installation, several
additional identical test VMs were created.
A total of eight VMs were used for parallel testing.
Multiple independent test VMs reproduced the same PID1/systemd failure
and kernel panic while configured with:
```xml
migratable='off'
```
For example, independent test VMs reproduced the same:
```text
Attempted to kill init
```
failure/error code.
This makes corruption of one particular guest filesystem/image unlikely.
In the latest parallel test, two VMs using normal `migratable='off'`
crashed again, while the VMs using `migratable='on'` remained stable.
---
## Important workaround
Changing:
```xml
<cpu mode='host-passthrough' check='none' migratable='off'>
```
to:
```xml
<cpu mode='host-passthrough' check='none' migratable='on'>
```
has so far made the affected VMs stable.
This is currently also being used as the workaround for the
production/storage VM.
No other VM configuration change is required for this workaround.
---
## CPU feature difference
CPU flags exposed inside otherwise comparable guests were compared
between `migratable='off'` and `migratable='on'`.
The following guest-visible CPU flags are present only with
`migratable='off'`:
```text
constant_tsc
ibt
nonstop_tsc
user_shstk
```
No additional flags were found only in the `migratable='on'` case.
`waitpkg` remains exposed in both configurations.
Therefore the currently known guest-visible difference is:
```text
migratable=off:
constant_tsc
ibt
nonstop_tsc
user_shstk
migratable=on:
none of the above
```
---
## invtsc isolation test
QEMU/libvirt on this host exposes `invtsc` as a configurable CPU
feature.
An additional test is currently running with:
```xml
<cpu mode='host-passthrough' check='none' migratable='off'>
<topology sockets='1' dies='1' clusters='1' cores='2' threads='1'/>
<cache mode='passthrough'/>
<feature policy='disable' name='invtsc'/>
</cpu>
```
This test is intended to determine whether invariant-TSC exposure is
responsible for the difference between `migratable=off` and
`migratable=on`.
Status at time of report:
```text
migratable=off -> reproducibly crashes
migratable=on -> stable so far
migratable=off + invtsc disabled -> test still running
```
I will update the report when the `invtsc` test has run long enough to
be meaningful.
---
## WAITPKG test
WAITPKG/TPAUSE was initially suspected because inspection of a frozen
guest showed one vCPU stuck around `delay_halt_tpause`.
A test was therefore performed with WAITPKG disabled:
```xml
<feature policy='disable' name='waitpkg'/>
```
The guest still failed after approximately 22 minutes with the same
repeated systemd segmentation faults.
Therefore WAITPKG is not required to reproduce the problem.
---
## Frozen-vCPU investigation
During one frozen run, the QEMU process was still alive and libvirt
reported:
```text
running
```
The QEMU guest agent no longer responded.
One guest vCPU thread was consuming approximately 100% of one host CPU.
Registers captured from that vCPU included:
```text
RDI=0000163ac28e3d75
RSI=000000000013b5eb
RAX=0000163ac2a1f360
RDX=000000000000163a
ECX=0000000000000000
RIP=ffffffff8991506a
RFL=0000000000000202
CPL=0
HLT=0
```
Ten RIP samples taken approximately one second apart showed the exact
same RIP.
Memory around the RIP was:
```text
ffffffff89915050: 0f 1f 44 00 00 55 48 8d
ffffffff89915058: 04 37 31 c9 48 89 c2 48
ffffffff89915060: c1 ea 20 48 89 e5 66 0f
ffffffff89915068: ae f1 5d 31 c0 31 d2 31
ffffffff89915070: c9 31 f6 31 ff c3 cc cc
```
This decodes approximately as:
```text
push rbp
lea (rdi,rsi),rax
xor ecx,ecx
mov rax,rdx
shr $0x20,rdx
mov rsp,rbp
tpause ecx
pop rbp
...
ret
```
After rebooting the same guest kernel, `/proc/kallsyms` showed:
```text
ffffffff92115040 t __pfx_delay_halt_tpause
ffffffff92115050 t delay_halt_tpause
```
The low address offset matches the frozen RIP, identifying the frozen
location as approximately:
```text
delay_halt_tpause+0x1a
```
immediately after TPAUSE.
However, because disabling WAITPKG did NOT prevent the original
systemd/PID1 corruption and panic, I do not currently consider this
evidence that TPAUSE is the root cause. It may only be a secondary state
reached after the guest has already malfunctioned.
---
## Guest kernel test
The issue was originally reproduced with Ubuntu guest kernel:
```text
7.0.0-31
```
To determine whether this was a guest kernel 7.0 regression, the guest
was also tested with:
```text
6.17.0-41-generic
```
The failure still occurred, with repeated systemd/libc segmentation
faults after approximately 33 minutes.
Therefore guest kernel 7.0 is not required to reproduce the issue.
---
## Single-vCPU test
The VM was also tested with only one vCPU.
The same type of failure occurred after approximately 5647 seconds (~94
minutes).
The segmentation fault was then reported as occurring on CPU0.
Therefore:
* a second guest vCPU is not required
* guest SMP is not required
* the problem is not specific to guest vCPU1
---
## Host CPU pinning test
The original VM used different pinned host CPUs.
To exclude a defective/specific host core, guest vCPUs were moved to
other host CPUs, including host CPUs 1 and 2.
The failure remained reproducible.
Additional parallel VMs were also assigned different host CPU cores and
multiple VMs reproduced the same failure.
Therefore the problem does not appear to be limited to one particular
host logical CPU/core.
---
## PCI passthrough test
The original VM passed through several PCI devices, including
storage/network controllers.
The issue was subsequently reproduced in test VMs without PCI
passthrough.
Therefore VFIO/PCI passthrough is not necessary to reproduce the
problem.
---
## Host stability
During guest failures:
* host remains responsive
* no host kernel panic occurs
* other host functionality continues operating
* QEMU process remains present
* libvirt can still report the failed VM as running
Host CPU/RAM stress testing has also completed without reproducing
corruption on the host.
This does not completely exclude a hardware or microcode problem, but
the strong dependency on `migratable=off` versus `migratable=on`
currently points more strongly toward KVM/QEMU CPU feature exposure or a
host-kernel/KVM issue.
---
## Relevant host kernel observations
The host kernel recognizes the CPU as:
```text
Intel(R) Core(TM) i5-14400
family: 0x6
model: 0xb7
stepping: 0x1
```
The host also enables the relevant x86 control-flow xstate components:
```text
x86/fpu: Supporting XSAVE feature 0x800: 'Control-flow User registers'
x86/fpu: Supporting XSAVE feature 0x1000: 'Control-flow Kernel registers (KVM
only)'
x86/fpu: Enabled xstate features 0x1a07, context size is 880 bytes, using
'compacted' format.
```
No host crash corresponding to the guest failures has been observed.
---
## Similar Fedora issue
This appears very similar to:
Red Hat Bugzilla #2448303:
"KVM guest will get kernel panic or freeze when migratable setting is off"
That report describes:
* `host-passthrough`
* `migratable='off'`
* random guest panic/freeze
* failures ranging from boot time to 1-2 hours
* multiple guest kernel versions
* exact panic codes including:
```text
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000008b
```
The Fedora reporter also reports that an older host kernel is stable
with `migratable='off'`, while newer host kernels reproduce the issue.
The Fedora report states that the issue first appeared with Fedora host
kernel 6.18.3 and was also reproducible with a Rawhide 7.0 release-
candidate kernel.
This similarity is why I suspect a host-side KVM/x86 regression rather
than a guest-specific issue.
---
## Additional comparison system
For comparison, another independent virtualization host using an Intel
Core i9-12900K has been running VMs with:
```xml
migratable='off'
```
without this failure.
That host currently uses:
```text
Linux 7.0.0-30-generic
```
and has guests including Linux 6.8.x and Windows VMs.
Therefore `migratable='off'` itself is not universally broken.
Potentially relevant differences include:
* affected host: Intel Core i5-14400 / Raptor Lake Refresh
* unaffected host: Intel Core i9-12900K / Alder Lake
* affected host kernel: Ubuntu 7.0.0-31-generic
* unaffected comparison host kernel: Ubuntu 7.0.0-30-generic
A controlled test of the affected i5-14400 host with Ubuntu host kernel
`7.0.0-30-generic` and `migratable='off'` has not yet been performed.
---
## Reproduction procedure
1. Create a Q35/OVMF KVM guest.
2. Configure CPU as:
```xml
<cpu mode='host-passthrough' check='none' migratable='off'>
<topology sockets='1' dies='1' clusters='1' cores='2' threads='1'/>
<cache mode='passthrough'/>
</cpu>
```
3. Boot an Ubuntu Linux guest.
4. Leave the VM running.
5. After a variable period, usually tens of minutes to approximately 1.5
hours, observe systemd/PID1 segmentation faults and eventually either a
guest freeze or:
```text
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000008b
```
6. Change only:
```text
migratable='off'
```
to:
```text
migratable='on'
```
7. Repeat the test.
Result so far: the `migratable='on'` guests remain stable while
otherwise comparable `migratable='off'` guests reproduce the failure.
---
## Tests performed / current results
```text
PCI passthrough removed:
FAILS
-> PCI passthrough not required
Different host CPU pinning:
FAILS
-> not limited to original host cores
WAITPKG disabled:
FAILS
-> WAITPKG not required
Guest kernel 6.17 instead of 7.0:
FAILS
-> not specific to guest kernel 7.0
Only one guest vCPU:
FAILS
-> guest SMP / second vCPU not required
Multiple independent guest VMs:
FAIL
-> not specific to one guest installation/image
migratable='off':
REPRODUCIBLY FAILS
migratable='on':
STABLE SO FAR
migratable='off' + invtsc disabled:
TEST CURRENTLY RUNNING
```
---
## Expected result
A guest using `host-passthrough` with `migratable='off'` should not
suffer random userspace corruption, PID1 segmentation faults, kernel
panic or complete guest freeze.
---
## Actual result
Guests reproducibly develop apparently random segmentation faults and
eventually panic or freeze.
Changing only the CPU migration filtering from `migratable='off'` to
`migratable='on'` prevents the failure in testing so far.
---
## Information that can be provided
I can provide additional sanitized information if useful, including:
* full `virsh dumpxml`
* `virsh domcapabilities`
* host `dmesg`
* host `/proc/cpuinfo`
* guest `/proc/cpuinfo`
* exact CPU flag comparison for migratable on/off
* QEMU/libvirt versions
* `/var/log/libvirt/qemu/<domain>.log`
* additional crash screenshots
* additional vCPU register dumps from a frozen guest
* results of the ongoing `invtsc` isolation test
* test results using Ubuntu host kernel 7.0.0-30 on the affected machine
Troubleshooting and organization of the collected observations were
assisted by ChatGPT. All reproduction results and commands/results
described above were manually observed/verified on the affected systems.
ProblemType: Bug
DistroRelease: Ubuntu 26.04
Package: linux-image-7.0.0-31-generic 7.0.0-31.31
ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14
Uname: Linux 7.0.0-31-generic x86_64
AlsaDevices:
total 0
crw-rw---- 1 root audio 116, 1 Sep 5 19:43 seq
crw-rw---- 1 root audio 116, 33 Sep 5 19:43 timer
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.34.1-0ubuntu0.1
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq',
'/dev/snd/timer'] failed with exit code 1:
CRDA: N/A
CasperMD5CheckResult: pass
Date: Sun Sep 6 14:11:52 2026
InstallationDate: Installed on 2026-09-03 (3 days ago)
InstallationMedia: Ubuntu-Server 26.04.1 LTS "Resolute Raccoon" - Release amd64
(20260826)
MachineType: ASUS System Product Name
PciMultimedia:
ProcEnviron:
LANG=de_DE.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-31-generic
root=UUID=c474ff0a-e9b2-42c8-a9d5-90d0a434159b ro intel_iommu=on iommu=pt
i915.enable_guc=3 kvm.ignore_msrs=1 vfio-pci.ids=144d:a80a,1000:0097,1d6a:04c0
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/08/2026
dmi.bios.release: 40.3
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 4003
dmi.board.asset.tag: Default string
dmi.board.name: PRIME Z690M-PLUS D4
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: Default string
dmi.chassis.version: Default string
dmi.modalias:
dmi:bvnAmericanMegatrendsInc.:bvr4003:bd05/08/2026:br40.3:svnASUS:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEZ690M-PLUSD4:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:pfaTobefilledbyO.E.M.:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: System Product Name
dmi.product.sku: SKU
dmi.product.version: System Version
dmi.sys.vendor: ASUS
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug resolute
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2166603
Title:
KVM guests randomly panic/freeze with host-passthrough migratable=off,
stable with migratable=on
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166603/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
