On Mon, Jun 08, 2026 at 14:39:00 +0200, Denis V. Lunev wrote:
(sorry for later answer - I was on vacation last week).
On 6/1/26 15:44, Jiří Denemark wrote:
On Tue, May 26, 2026 at 17:17:10 +0200, Denis V. Lunev wrote:
qemuDomainMakeCPUMigratable() strips features marked added='yes' (in src/cpu_map/x86_*.xml) from the migration cookie when the source CPU was specified as host-model. The intent was libvirt-protocol compat with older destinations; the cost is guest CPU compat, paid silently on every migration. Sigh, yeah there's still (at least) one thing missing around vmx migration...
Every Intel x86 CPU model from Westmere through Sapphire Rapids carries 60+ added='yes' features, including vmx-exit-load-perf-global-ctrl and vmx-entry-load-perf-global-ctrl that control the LOAD_IA32_PERF_GLOBAL_CTRL allowed-1 bits of MSR_IA32_VMX_{EXIT,ENTRY}_CTLS. A host-model live migration on any of these models drops those features from the destination's qemu argv. Yeah, unless those vmx features are explicitly specified in the domain XML, libvirt adds them according to what QEMU enabled based on the -cpu command line and then removes them during migration. The assumption is that if QEMU automatically added them on the source host, it will also add them on the destination host.
I agree with this assumption, but the problem is subtle. Libvirt specifies these features using command line on source and misses them on target.
Hmm, somehow I managed to miss you were talking about host-model CPU. That changes the situation quite a bit. You're right we explicitly pass all those vmx features to QEMU in -cpu rather than adding them to the XML according to what QEMU enabled without asking. In my reply I was thinking about a custom CPU mode and we must not break that while fixing host-model. So instead of reverting the compatibility code, We should consider all features we eventually pass to -cpu on the source as explicitly requested. That is, even those that come from host-model CPU. This should fix the bug as the vmx features would not be dropped from the CPU definition during migration. The custom CPU mode would keep working as it is now and host-model has never been guaranteed to be migratable to older libvirt releases so we're not breaking anything. Jirka