[vbox-dev] fUpdateStuff flag never set in trunk/src/VBox/VMM/TM.cpp ?

[Mark Cranness]

2009/12/8 Knut St. Osmundsen <bird at sun.com>:
> Mark Cranness wrote:
>> http://www.virtualbox.org/browser/trunk/src/VBox/VMM/TM.cpp#L1953
>
> This is a genuine bug, thanks for spotting it.  I've fixed it internally
> and it should show up externally soon.

Thanks.
(I don't suppose there is any chance of a bugfix release to 3.0.12 also?)


>> Won't this cause the TSC catchup to always fail (because the catch-up
>> calculation is not written back)?
>
> No, it's stopped further down in the same function after we've done the
> timeout callouts.  I'm not actually sure if it's necessary to make these
> updates before we do the callouts - it's been a while since I worked on
> the code last.

The catch-up calculation I'm suggesting doesn't get written back (and
therefore there is no catchup) is:

Line 1988:    ASMAtomicWriteU64(&pVM->tm.s.offVirtualSync, off);

http://www.virtualbox.org/browser/trunk/src/VBox/VMM/TM.cpp#L1988

The catchup uses the current pVM->tm.s.u32VirtualSyncCatchUpPercentage
value (lines 1960 thru 1963) to set the 'off' variable, which needs to
get written back to tm.s.offVirtualSync by line 1988, but will not
because fUpdateStuff is not set.

Variable 'off' only has scope in the else clause between lines 1949
and 1996, and that else block is the only place in TM.cpp where
pVM->tm.s.u32VirtualSyncCatchUpPercentage is used in a multiplication
that can effect offVirtualSync, so there is no other chance (in
TM.cpp) to save the result of the catch-up attempt.

(I note that TMAllVirtual.cpp > tmVirtualSyncGetHandleCatchUpLocked()
/ ~ line 418 has a similar calculation.)


> The small parameter adjustment you did there won't help much on its own.
> And there are known issues with the catch-up not working correctly on
> certain setups.  We're looking into the latter and there should
> eventually be fixed once we have it figured out...

I can tell you what I've found, which I hope helps:

'Wall' time / GetSystemTime() in the guest seems to be linked to the
TSC counter.
(At least it is on my Windows 2000 Server guest, I'm not exactly sure why...)

BUT in my CPU, when the CPU is idling the TSC counter rate drops from
the full CPU 3GHz to 2GHz.
(Intel Core 2 Duo E8400 E0, which apparently does NOT have the
Invariant TSC feature: CPUID(80000007)[EDX] = 0)

This makes the system time in the guest run at 2/3 = 66.7% of normal
while the host is idle.  Every 3 minutes of real time, the guest time
has advanced only 2 minutes, at which point the 60 seconds difference
causes the TSC catchup to give up and add a message to the log and add
60 seconds to the guest time.

This happens every 3 minutes +/- only a couple of seconds, which leads
me to believe that NO catchup is actually happening, because at least
some of the time the TSC catchup should have been running at 3x or 4x
normal speed.

Even if catchup WAS happening, I suspect I would still get the give up
messages, because with the default values, the TSC is successful if
the lag gets below 0.5ms.  But the catchup rate when the lag is below
0.75ms is only +5%, which is not enough to overcome the 66.7% TSC
rate.
(This was why I was attempting to tweak
tmVirtualSyncGetHandleCatchUpLocked etc.)


Is the TSC problem with certain setups just as I have written above,
on CPUs that do not have Invariant TSC?

-- 
Thanks,
Mark