Re: [PATCH] KVM: x86: remove irq disablement around KVM_SET_CLOCK/KVM_GET_CLOCK

["Radim Krčmář" <rkrcmar@redhat.com>]

2017-04-13 10:32+0300, Roman Kagan:
> Hmm, __get_kvmclock_ns used not to need a spinlock back when it was
> added...  Why does it now?

It accessed vcpu to get the data it now takes from the master clock.
The lock is there to protect master clock's consistency.

There were problems when accessing VCPUs from VM ioctls -- you first had
to conjure a VCPU out of thin air and then be extremely careful when
accessing it, which we didn't manage to and it resulted in an invalid
VMCS access bug, IIRC.  (I would bet there we other bugs.)

> Looking at its current state, I'm not sure I understand what it's
> supposed to do: it uses the host tsc rate rather than the guest one,
> which seems to just defeat the purpose of originally introducing it: to
> have a way to obtain the clock value exactly the same as the guest would
> see...
> 
> Am I missing anything obvious?

It is a bit obscure ... the current state is simulating what the vcpu
does when setting up its kvmclock, and should therefore yield the same
result as the guest kvmclock would see.

Without master clock, the guest kvmclock follows ktime_get_boot_ns().

With master clock, the guest follows host TSC (different frequency than
ktime_get_boot_ns()).  The guest might have extra scaling and offset on
that TSC, but both are known to KVM when computing the kvmclock
variables to get the 1GHz result.

We could first convert the host TSC to guest TSC and then compute
kvmclock from it, but we should obtain the same result when converting
to 1GHz directly from host TSC (within rouding errors, ofc).

This is possible as guest and host use the same physical TSC.