Re: [PATCH] target/i386/kvm: Fix Live Migration failure on Intel Ice Lake after OS upgrade (Ubuntu 20.04 to 22.04)

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, May 12, 2026 at 11:02:37AM +0300, fatih şener wrote:
> Dear QEMU Developers,
> 
> We have identified a critical live migration failure on Intel Ice Lake
> platforms when using *CPU host-passthrough* in OpenStack environments. The
> issue specifically surfaced after upgrading compute nodes from *Ubuntu
> 20.04 to 22.04*.

IMHO that is not a valid usage scenario.

host-passthrough is only supportable with live migration if both sides
of the migration are *identical*. That means same CPU models, same
microcode version, same BIOS version, same BIOS settings, same kernel
version, same QEMU version. Vary any one of those factors as it looses
any guarantee of live migration safety for host-passthrough.

If those requirements can't be guaranteed, then we have a wide choice
of named CPU models that support migration across hosts with different
setups.

> *Technical Analysis:* The migration fails with KVM_SET_MSRS error while
> restoring MSR_IA32_PERF_GLOBAL_CTRL (0x38f). On Ice Lake CPUs, this
> register reports 0xf000000ff due to the 4th fixed-function counter (Perf
> Mon v5).
> 
> We observed that while the source host (20.04) allows this value, the
> target host (22.04 with a newer Kernel/KVM) enforces a stricter mask of
> 0x7000000ff. Even with identical hardware, the migration is rejected
> because the target KVM treats the 4th bit as reserved/invalid.
> 
> *Proposed Fix:* We propose intercepting the MSR write in
> target/i386/kvm/kvm.c to mask the value back to 0x7000000ff if 0xf000000ff
> is detected. This ensures backward compatibility across different kernel
> versions and stabilizes migration on Ice Lake hardware.
> 
> /* target/i386/kvm/kvm.c */
> for (i = 0; i < cpu->kvm_msr_buf->nmsrs; i++) {
>     if (cpu->kvm_msr_buf->entries[i].index == 0x38f &&
>         cpu->kvm_msr_buf->entries[i].data == 0xf000000ffULL) {
>         cpu->kvm_msr_buf->entries[i].data = 0x7000000ffULL;
>     }
> }
> 
> We have verified that this fix stabilizes our production environment and
> allows successful live migration between hosts with different kernel
> versions on Ice Lake hardware. We are looking forward to your technical
> feedback on this implementation. If there is a more architectural way to
> handle these MSR bitmasks upstream, we would be happy to discuss it. Best
> regards,
> -- 
> ● Fatih Şener - fatihsenerr@gmail.com

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|