2009/12/8 Knut St. Osmundsen <[email protected]>: > 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 _______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
