On 6/17/26 11:27, Jiří Denemark wrote:
> 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
>
yes. this approach is much better :-) The patch effectively
becomes 1-liner.Sent v2. Thank you for review, Den
