Marcelo Tosatti <mtosatti@xxxxxxxxxx> writes: > On Thu, Mar 18, 2021 at 06:50:35PM +0100, Paolo Bonzini wrote: >> On 18/03/21 17:57, Marcelo Tosatti wrote: >> > I think this should be monotonically increasing: >> > >> > 1. r1 = rdtsc(); >> > 2. t1 = rdmsr(HV_X64_MSR_TIME_REF_COUNT); >> > 3. nop_loop(); >> > 4. r2 = rdtsc(); >> > 5. t2 = rdmsr(HV_X64_MSR_TIME_REF_COUNT); >> > >> > > >> > > + /* 1% tolerance */ >> > > + GUEST_ASSERT(delta_ns * 100 < (t2 - t1) * 100); >> > > +} >> > >> > Doesnt an unbounded schedule-out/schedule-in (which resembles >> > overloaded host) of the qemu-kvm vcpu in any of the points 1,2,3,4,5 >> > break the assertion above? >> >> >> Yes, there's a window of a handful of instructions (at least on >> non-preemptible kernels). If anyone ever hits it, we can run the test 100 >> times and check that it passes at least 95 or 99 of them. >> >> Paolo > > Yep, sounds like a good solution. > > However this makes me wonder on the validity of the test: what its > trying to verify, again? (i would check the monotonicity that > is r1 <= t1 <= r2 <= t2 as well, without the nop_loop in between). This particular place tests that Reference TSC (HV_X64_MSR_TIME_REF_COUNT) is a 1Ghz clock. We test it against raw TSC. TSC frequency is known to us (HV_X64_MSR_TSC_FREQUENCY) so we can compare the delta after nop_loop(). We can't directly compare r1 and t1 (and r2 and t2) here because we don't know the base precisely. We could've probably reset TSC to 0 and kvmclock (which converts to Reference TSC) to 0 and compare after. For now, we just check that Reference TSC is ticking as it should. -- Vitaly
