On Mon, 2020-11-30 at 15:33 +0100, Paolo Bonzini wrote:
> On 30/11/20 14:35, Maxim Levitsky wrote:
> > + if (guest_cpuid_has(vcpu, X86_FEATURE_TSC_ADJUST)) {
> > + tsc_state.tsc_adjust = vcpu->arch.ia32_tsc_adjust_msr;
> > + tsc_state.flags |= KVM_TSC_STATE_TSC_ADJUST_VALID;
> > + }
>
> This is mostly useful for userspace that doesn't disable the quirk, right?
Isn't this the opposite? If I understand the original proposal correctly,
the reason that we include the TSC_ADJUST in the new ioctl, is that
we would like to disable the special kvm behavior (that is disable the quirk),
which would mean that tsc will jump on regular host initiated TSC_ADJUST write.
To avoid this, userspace would set TSC_ADJUST through this new interface.
Note that I haven't yet disabled the quirk in the patches I posted to the qemu,
because we need some infrastructure to manage which quirks we want to disable
in qemu
(That is, KVM_ENABLE_CAP is as I understand write only, so I can't just disable
KVM_X86_QUIRK_TSC_HOST_ACCESS, in the code that enables x-precise-tsc in qemu).
>
> > + kvm_get_walltime(&wall_nsec, &host_tsc);
> > + diff = wall_nsec - tsc_state.nsec;
> > +
> > + if (diff < 0 || tsc_state.nsec == 0)
> > + diff = 0;
> > +
>
> diff < 0 should be okay. Also why the nsec==0 special case? What about
> using a flag instead?
In theory diff < 0 should indeed be okay (though this would mean that target,
has unsynchronized clock or time travel happened).
However for example nsec_to_cycles takes unsigned number, and then
pvclock_scale_delta also takes unsigned number, and so on,
so I was thinking why bother with this case.
There is still (mostly?) theoretical issue, if on some vcpus 'diff' is positive
and on some is negative
(this can happen if the migration was really fast, and target has the clock
A. that is only slightly ahead of the source).
Do you think that this is an issue? If so I can make the code work with
signed numbers.
About nsec == 0, this is to allow to use this API for VM initialization.
(That is to call KVM_SET_TSC_PRECISE prior to doing KVM_GET_TSC_PRECISE)
This simplifies qemu code, and I don't think
that this makes the API much worse.
Best regards,
Maxim Levitsky
>
> Paolo
>
