VMware patches for Ubuntu

[Alok Kataria]

On Fri, 2008-11-07 at 11:35 -0800, Tim Gardner wrote:
> Alok Kataria wrote:
> > On Thu, 2008-11-06 at 18:33 -0800, Tim Gardner wrote:

> > 
> > 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

Nope i was talking about the merge of 32 bit and 64bit for tsc code,
which happened in 2.6.26 cycle. 

I should be able to backport these hypervisor detection patches for the
24 tree, but let me see if and how to do that.

> 
> > 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.

Ya, i agree, but the detection algorithm is robust enough that we should
not have any regressions for native. 

> 
> >> 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.

Thats cool, so that would mean you can easily cherry pick these patches
for the intrepid tree. Can you let me know for which release can we
expect to see these patches.

Also i noticed some mails about the "jaunty" release, would that be
rebased to 2.6.29 later ? If its going to be based off 28, can you
cherry pick these patches for jaunty too, since these patches will be
upstreamed during the 29 merge cycle.

Thanks,
Alok

> 
> rtg