[much snippage] On Thu, Mar 26, 2015 at 1:58 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > If the versioning were fixed, I think we could almost get away with: > > pvti = pvti for vcpu 0; > > ver1 = pvti->version; > check stable bit; > rdtsc_barrier, rdtsc, read scale, shift, etc. > if (pvti->version != ver1) retry; > > This guarantees that the tsc came from an interval in which vcpu0's > kvmclock was *marked* stable. If vcpu0's kvmclock were genuinely > stable in that interval, then we'd be fine, but there's a race window > in which the kvmclock is *not* stable and vcpu 0 wasn't running. Rik pointed out that this could actually be okay. Apparently vcpu 0 is somewhat special, and it may actually be impossible to switch from stable to unstable which a vcpu other than 0 is running and vcpu0 hasn't updated its kvmclock data. --Andy > > Why doesn't KVM just update all of the kvmclock data at once? (For > that matter, why is the pvti in guest memory at all? Wouldn't this > all be simpler if the kvmclock data were host-allocated so the host > could write it directly and maybe even share it between guests?) > > --Andy -- Andy Lutomirski AMA Capital Management, LLC -- 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
