On Fri, Jan 19, 2024 at 02:46:22PM +0800, Xiaoyao Li wrote: > I'm wondering why CPUID_APM_INVTSC is set as unmigratable_flags. Could > anyone explain it?
commit 68bfd0ad4a1dcc4c328d5db85dc746b49c1ec07e Author: Marcelo Tosatti <mtosa...@redhat.com> Date: Wed May 14 16:30:09 2014 -0300 target-i386: block migration and savevm if invariant tsc is exposed Invariant TSC documentation mentions that "invariant TSC will run at a constant rate in all ACPI P-, C-. and T-states". This is not the case if migration to a host with different TSC frequency is allowed, or if savevm is performed. So block migration/savevm. So the rationale here was that without ensuring the destination host has the same TSC clock frequency, we can't migrate. However, this was later extended to allow invtsc migratioon when setting tsc-khz explicitly: commit d99569d9d8562c480e0befab601756b0b7b5d0e0 Author: Eduardo Habkost <ehabk...@redhat.com> Date: Sun Jan 8 15:32:34 2017 -0200 kvm: Allow invtsc migration if tsc-khz is set explicitly We can safely allow a VM to be migrated with invtsc enabled if tsc-khz is set explicitly, because: * QEMU already refuses to start if it can't set the TSC frequency to the configured value. * Management software is already required to keep device configuration (including CPU configuration) the same on migration source and destination. Signed-off-by: Eduardo Habkost <ehabk...@redhat.com> Message-Id: <20170108173234.25721-3-ehabk...@redhat.com> Signed-off-by: Eduardo Habkost <ehabk...@redhat.com> And support for libvirt was added: https://listman.redhat.com/archives/libvir-list/2017-January/141757.html > > When the host supports invtsc, it can be exposed to guest. > When the src VM has invtsc exposed, what will forbid it to be migrated to a > dest that also supports VMs with invtsc exposed? > >