VMware patches for Ubuntu

[Tim Gardner]

Alok Kataria wrote:
> On Thu, 2008-11-06 at 18:33 -0800, Tim Gardner wrote:
>>> Commit id's are
>>>
>>> commit b2bcc7b299f37037b4a78dc1538e5d6508ae8110
>>> commit 49ab56ac6e1b907b7dadb72a4012460359feaf0e
>>> commit 88b094fb8d4fe43b7025ea8d487059e8813e02cd
>>> commit eca0cd028bdf0f6aaceb0d023e9c7501079a7dda
>>> commit 395628ef4ea12ff0748099f145363b5e33c69acb
>>> commit 6bdbfe99916398dbb28d83833cc04757110f2738
>>> commit fd8cd7e1919fc1c27fe2fdccd2a1cd32f791ef0f
>>>
>>> These patches are discussed mainly on this thread,
>>> http://lkml.org/lkml/2008/10/22/523
>>>
>>> Let me know if you have any questions.
>>>
>>> Thanks,
>>> Alok
>>>
>> I'm quite reluctant to apply these patches to an LTS kernel without your
>> assurance that they've been well tested on 2.4.24. 
> 
> You mean 2.6.24 here...yes i had done some testing for the Ubuntu kernel
> but this was quite early when the patch looked quite different than the
> final version. 
> So i think i will have to backport these for the 2.6.24 tree (which
> doesn't have merged tsc code), but anyways doing that (backport) and
> testing it should be trivial, i will do that and send you the backported
> patches soon.
> 

The Hardy 2.6.24 kernel has this series (which I think is the tsc code):

x86: tsc prevent time going backwards
x86: implement support to synchronize RDTSC through MFENCE on AMD CPUs
x86: Implement support to synchronize RDTSC with LFENCE on Intel CPUs
x86: move nop declarations into separate include file
x86: introduce rdtsc_barrier()
x86: remove get_cycles_sync
x86: read_tsc sync
UBUNTU: Add native_read_tsc to non __i386__ code.
Add barriers to native_read_tsc
UBUNTU: Use readtsc-barrier in xen

> Just to clarify, you agree that the testing required is only for guests
> running under VMware, while running natively it should have no side
> affect apart from the execution of detection code.
> 

Even though these patches only affect guests, I still have to worry
about regressions.

>> How about 2.6.27?
> 
> Yep these patches have been tested against 2.6.27 mainline, so we should
> be good for intrepid i guess.
> 
> One thing that has come up while discussing these patches with the
> distribution folks, these patches add a field to the x86_cpuinfo
> structure, so it may mean breaking the kABI, i can add a global
> x86_hyper_vendor variable instead of the per-cpu one if that's needed. 
> Also please let me know if there are any other tests that i should run
> to check that no other changes break the kABI for ubuntu.
> 

I'm not so concerned about kABI changes, they can happen for a variety
of reasons. However, one of my goals is to get third party module
developers (like VMware) to use DKMS for packaging. That way kABI
changes are no longer an issue.

rtg
-- 
Tim Gardner tim.gardner at canonical.com