Kernel panic - not syncing: VIRQ mismatch

KVM Hypervisor Kernel Crash: Fix It Now

Server & Cloud Intermediate 👁 12 views 📅 Jun 25, 2026

KVM hypervisor kernel crashes happen. Most common cause: faulty CPU features. We'll fix the three main reasons step by step.

1. CPU Feature Mismatch (EPT and VPID Bugs)

This is the number one reason KVM hypervisors crash. The kernel panic message usually looks like:

Kernel panic - not syncing: VIRQ mismatch: CPU0 has 0x4, CPU1 has 0x0

You see this on older Intel CPUs (Westmere, Sandy Bridge) or when you enable nested virtualization with buggy microcode. The real fix is to disable EPT (Extended Page Tables) and VPID (Virtual Processor IDs) in the KVM module.

Step-by-step fix

  1. SSH into your hypervisor. Don't do this on a running production VM — you'll need to reload the KVM module.
  2. Check current KVM module parameters:
cat /sys/module/kvm_intel/parameters/ept
cat /sys/module/kvm_intel/parameters/vpid

If both are set to 'Y', that's the problem.

  1. Create a configuration file to disable them permanently:
echo "options kvm_intel ept=0 vpid=0" | sudo tee /etc/modprobe.d/kvm-intel.conf

After saving this file, you should see the new parameters listed when you run cat /etc/modprobe.d/kvm-intel.conf.

  1. Rebuild initramfs for the changes to take effect:
sudo update-initramfs -u -k all

This will regenerate the initial ramdisk. It takes about 10-20 seconds on most systems.

  1. Reboot:
sudo reboot

After the reboot, run cat /sys/module/kvm_intel/parameters/ept again. You should see 'N' now. If you still see 'Y', the module didn't load your config — check that the filename ends with .conf.

Performance note: Disabling EPT can slow down memory-intensive VMs by 10-20%. But a crashing hypervisor is worse than a slower one. If you have AMD CPUs, use kvm_amd instead of kvm_intel, and disable npt=0 (not ept).

2. Nested Virtualization Conflicts

Nested virtualization means running a VM inside another VM. This crashes the host kernel when you try to pass through PCI devices or use certain CPU features. You'll see errors like:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
IP: [] nested_vmx_exit_handled+0x40/0x120 [kvm_intel]

This happens because nested KVM tries to handle VMX instructions that the L1 hypervisor (the host) doesn't expect. The fix is to disable nested virtualization on the host.

Fix it: turn off nested

  1. Check if nested is enabled:
cat /sys/module/kvm_intel/parameters/nested

If it shows 'Y', that's likely your crash source.

  1. Disable it:
echo "options kvm_intel nested=0" | sudo tee /etc/modprobe.d/kvm-nested.conf

Don't use the same config file as before — keep them separate. It's easier to debug later.

  1. Update initramfs and reboot:
sudo update-initramfs -u -k all
sudo reboot

After reboot, confirm it's disabled: cat /sys/module/kvm_intel/parameters/nested should show 'N'.

When you still need nested virtualization: If you really must run VMs inside VMs (for testing or training), use an older kernel. Kernel 5.10 LTS handles nested KVM better than 5.15 or 6.x. Also set kvm_intel.nested=1 but only if you're on a very recent CPU (Intel Skylake or newer).

3. VFIO Passthrough Device Conflicts

This one happens when you pass a GPU or NVMe drive directly to a VM. The kernel crash looks like:

DMAR: [FATAL] INTR-REMAP: Request device [xx:xx.x] fault index 0x0
vfio-pci: 0000:xx:xx.x: failed to setup INTx for device

You get this because the IOMMU group is broken or the device isn't fully isolated. Common on consumer motherboards (Z690, X570) where PCIe slots share IOMMU groups with onboard devices like WiFi or audio.

Fix it: use ACS override patch

  1. First, check if you're in the right IOMMU group:
for g in /sys/kernel/iommu_groups/*; do
  echo "IOMMU Group $(basename $g):"
  ls $g/devices/
done

Look at the output. If your GPU (e.g., 0000:0a:00.0) shares a group with your sound card or another device, that's the problem.

  1. Add the ACS override patch to kernel boot parameters. Edit /etc/default/grub:
sudo nano /etc/default/grub

Find the line that starts with GRUB_CMDLINE_LINUX_DEFAULT. Add these parameter:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pcie_acs_override=downstream,multifunction intel_iommu=on"

Make sure to keep any existing parameters (like quiet splash).

  1. Update GRUB:
sudo update-grub

You should see it regenerating the boot menu — this takes about 5 seconds.

  1. Reboot:
sudo reboot

After reboot, check that the VFIO driver binds to the device properly:

lspci -nnk | grep -A2 "VGA compatible"

You should see Kernel driver in use: vfio-pci instead of nvidia or amdgpu.

If it still crashes: The ACS override patch isn't a perfect fix. Some motherboards (especially ASUS) have broken BIOS that doesn't report IOMMU groups correctly. In that case, your only option is to move the device to a different PCIe slot. The top x16 slot is usually in its own group.

Quick-Reference Summary

Cause Symptoms Fix Commands
CPU feature mismatch VIRQ mismatch panic, crash on VM start Disable EPT and VPID options kvm_intel ept=0 vpid=0
Nested virtualization NULL pointer dereference in nested_vmx Disable nested virtualization options kvm_intel nested=0
VFIO device conflict DMAR fault, failed to setup INTx ACS override patch pcie_acs_override=downstream,multifunction

Was this solution helpful?