qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why invtsc (CPUID_APM_INVTSC) is unmigratable?


From: Marcelo Tosatti
Subject: Re: Why invtsc (CPUID_APM_INVTSC) is unmigratable?
Date: Fri, 19 Jan 2024 13:14:43 -0300

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 <mtosatti@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 <ehabkost@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 <ehabkost@redhat.com>
    Message-Id: <20170108173234.25721-3-ehabkost@redhat.com>
    Signed-off-by: Eduardo Habkost <ehabkost@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?
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]