Hello!
In one of my 32-bit XP SP3 guests under VMware Workstation (6.0.5 and 8.0.3), I use hardware TSC (monitor_control.virtual_rdtsc = “FALSE” in .vmx file) to perform fine-grained time measurements.
If VirtualKD (2.5-2.7) debug transport is used and kernel debugger is connected, guest cannot detetmine processor clock frequency properly. HARDWAREDESCRIPTIONSystemCentralProcessor~MHz is 700..1000 instead of about 2400 (T8300@2.4 GHz, 32-bit XP SP3 host) and my own TSC-based measurement code gets highly variable values from 10-20 consecutive measurements.
During measurement, HAL code and my own code does not produce debug messages so the effect is deferred somehow.
If no kernel debugger connected and/or com/pipe transport is used, timer problem does not occur. Both ~MHz registry value and my own TSC-based measurements give almost the same frequency values.
If TSC is virtualized (default behavior), system timer works well too regardless of debug transport and/or debugger connection.
BTW, original XP SP3 HAL usually crashes in such mode due to an overflow. It is because HalpScaleTimers and HalpPmTimerScaleTimers do not save a TSC value before making a calibration delay; instead, they simply clear TSC by writing to the MSR and interpret TSC value after a delay as a relative one.
I have patched this code, allowing to use hardware TSC in a guest (the patch is attached for information).The patch modifies this code to save a previous TSC value and subtract it from a value sampled after a delay.