On Wed, Jan 18, 2017 at 05:04:27PM +0100, Phil Dennis-Jordan wrote:
> Thanks for the comments Paulo and Eduardo,
>
> On 18 January 2017 at 16:05, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
> >
> > > + DEFINE_PROP_BOOL("vmware-tsc-apic-clocks", X86CPU,
> > vmware_clock_rates, false),
> >
> > Maybe just vmware-cpuid-freq instead? Whatever the choice, please make
> > the bool field in struct X86CPU consistent with the property name (e.g.
> > enable_vmware_cpuid_freq).
> >
>
> Sounds good, I've fixed this and the page/leaf terminology mixup for the
> next patch iteration.
>
> One issue is that the TSC frequency can change, for example on
> > migration. Telling the guest about the TSC frequency makes little sense
> > if it can change.
> >
>
> That makes sense. Darwin can't handle changing TSC frequencies in any case,
> regardless of cpuid leaf 0x40000010. Do I deduce correctly from the
> following code (lines 967~977) that this bit inhibits migration
> intrinsically, so other than depending on it, I don't need to specifically
> disable migration for this option?
>
> if (c && (c->edx & 1<<8) && invtsc_mig_blocker == NULL) {
> …
> vmstate_x86_cpu.unmigratable = 1;
>
> (Likewise, it would appear that the user_tsc_khz case Eduardo suggested
> already has a migration sanity check in cpu_post_load() too.)
user_tsc_khz won't inhibit migration completely, but QEMU will
refuse to start if the host TSC frequency isn't an exact match
and the host doesn't support TSC scaling.
invtsc currently inhibits migration, but I have submitted a
series last week that will allow migration with invtsc if
user_tsc_khz is set.
There are also plans to allow very small TSC frequency mismatches
with tsc_user_khz set, so migration with tsc_user_khz can be
possible when TSC scaling is unavailable.
The discussion is at:
Subject: [PATCH 0/4] Allow migration with invtsc if there's no frequency mismatch
--
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
