Going from CentOS5 to CentOS6 and the kernel change from 2.6.18 to 2.6.32 breaks the timer calibration and makes the system almost totally unusable (also on other 2.6.32 or newer based distros).

There's no VT-x on the Atom so HPET is turned off. However, I can observe the effect also on a Mac Mini w/ VirtualBox 4. The impact is not as dramatic as the Core2Duo on the Mac provides more performance to begin with. But the delay loop calibration on the Mac is also off (and not showing the value 2.6.18 shows).

and it's still the same phenomena. It can be also observed on a Mac Mini w/ an Core2Dua which gives a lot more horsepower compared to the Atom 330 (and thus it's not that obvious) but still can be seen.
Was wondering if this is going to be addressed eventually?

Not seen in the same configuration on a different host (VBox 4.1.20 on a Mac Mini with Intel Core2 Duo CPU). But the Timer calibration seems to be way off on that platform as well even though this box has HardwareVirtEx (and the Atom box does not).

I would really like to see at least some confirmation here since incorrect timer calculation potentially affects a lot more users...

You are right, this patch adds some hypervisor-specific code to the Linux kernel to make the detection of the TSC frequency more reliable and actually this is the only way to fix this problem. On the other hand, the code you mention is specific to VMware and emulating this functionality would mean to make VirtualBox appear a bit like VMware, ie. implement at least parts of the VMware backdoor. This can have negative consequences to other software which now could think that it runs straight on VMware and could use certain features of the backdoor which are not implemented.

I think we have to go this way sooner or later but this needs a lot of tests.

Well, agreed that VirtualBox should not identify itself as VMware (even though that would help with older kernels when having this feature would automatically do 'the right thing'). Also note that the comment explicitly mentions 'implementing compatibility modes for other hypervisors'. But in fact, there should be a 'virtualbox.c' with VirtualBox specific detection code / TSC frequency fetching code. Looking at hypervisor.cVirtualBox is actually missing the party as of today...

I still see this same issue and can reproduce it reliably on many of our dev laptops. @rschmied , did you ever figure a work around? I would love to be able to work around this without needing to change out .vbox base images.