On Fri, Jan 06, 2017 at 08:31:27AM -0200, Marcelo Tosatti wrote:
[...]
> >
> > > Maybe your use case just needs a explicit "invtsc-migration=on"
> > > command-line flag without a mechanism to abort migration on
> > > mismatch? I can't tell.
> >
> > Again, there is no special case.
> >
> > > Note that even if we follow your suggestion and implement an
> > > alternative version of patch 4/4 to cover your use case, I will
> > > strongly recommend libvirt developers to support configuring TSC
> > > frequency if they want to support invtsc + migration without
> > > surprising/unpredictable restrictions on migratability.
> >
> > Well, alright. If you make the TSC frequency of the host
> > available to mgmt software as you describe, and write the steps mgmt
> > software should take, i'm good.
>
> I plan to. The problem is that the mechanism to query the host
> frequency may be unavailable in the first version.
Well just export KVM_GET_TSC_KHZ in a QMP command right? Its pretty
easy.
Let me know if you need any help coding or testing.
I just found out that KVM doesn't provide something that QEMU and
libvirt need: the value of kvm_max_guest_tsc_khz. Without it, we
have no way to know if a given VM is really migratable to a host.
Could we add a KVM_CAP_MAX_TSC_KHZ capability for that?
--
Eduardo