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
