Bug#524542: Patches to fix bugs related to TSC clocksource on VMware
Package: linux-2.6
Version: 2.6.26-13
This is regarding some patches which improve timekeeping for Linux when
running under VMware. Without these patches we may see incorrect
timekeeping with Debian's lenny kernel when running as guest under
VMware.
VMware hypervisor exports a consistent TSC to the guest for timekeeping
purposes, but still due to some kernel assumptions which don't hold true
in virtualization environments, the kernel can mark the TSC unstable and
hence unusable for timekeeping purposes.
Without these patches TSC cannot be used as a reliable clocksource under
VMware.
The problems with TSC assumptions in the kernel are as follows.
1) TSC calibration : TSC calibration maybe error prone in virtualized
environment, and since an error in TSC frequency may accumulate during
the kernels runtime, its important to keep the error to the minimum. The
best way to get the TSC frequency is to ask the hypervisor for that.
2) With the NO-HZ kernel, there is no guarantee that the acpi_pm timer
will be sampled at least every 4.68 seconds (the wrap interval), because
the vcpu, in extreme circumstances, may not have a chance to run in that
time. Thus, the acpi_pm timer is not suitable to be used as a
clocksource watchdog when running on a hypervisor.
3) Virtual TSCs can be kept nearly in sync, but because the virtual TSC
offset is set by software, it's not perfect. So, the TSC
synchronization test at bootup can fail. (Really, it can fail on native
as well, and that's why the tests for backwards TSC were added to
read_tsc()/vread_tsc()). We need a way to skip this check when on
VMware.
These patches add some VMware detection code which we use to get around
these TSC assumptions which fail under VMware's hypervisor.
Please note that these patches are not VMI ( paravirt) specific, and
change the default kernel for 32 and 64bit, but the modifications come
into affect only when we are running under VMware. Just the init and
detection code is run for native case.
This will also change the kABI, as it adds a field to the cpuinfo_x86
structure.
The mainline commit id's are
commit b2bcc7b299f37037b4a78dc1538e5d6508ae8110
x86: add a synthetic TSC_RELIABLE feature bit
commit 49ab56ac6e1b907b7dadb72a4012460359feaf0e
x86: add X86_FEATURE_HYPERVISOR feature bit
commit 88b094fb8d4fe43b7025ea8d487059e8813e02cd
x86: Hypervisor detection and get tsc_freq from hypervisor
commit eca0cd028bdf0f6aaceb0d023e9c7501079a7dda
x86: Add a synthetic TSC_RELIABLE feature bit.
commit 395628ef4ea12ff0748099f145363b5e33c69acb
x86: Skip verification by the watchdog for TSC clocksource.
commit 6bdbfe99916398dbb28d83833cc04757110f2738
x86: VMware: Fix vmware_get_tsc code
commit fd8cd7e1919fc1c27fe2fdccd2a1cd32f791ef0f
x86: vmware: look for DMI string in the product serial key
These patches have been included in the Ubuntu intrepid kernel as well
which is 2.6.27, so if its easier you may cherry pick those patches from
that tree. The only reason it might be easier is because IMO it would
require less or no effort to backport it to Lenny from Intrepid rather
than from mainline where these patches were applied in the 2.6.29 cycle.
Thanks,
Alok
Reply to: