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.
