Re: 2.6.35-rc1 regression with pvclock and smp guests

[Arjan Koers <0h61vkll2ly8@xutrox.com>]

On 2010-10-09 00:06, Marcelo Tosatti wrote:
> On Thu, Oct 07, 2010 at 04:47:11PM -1000, Zachary Amsden wrote:
>> On 10/07/2010 02:12 PM, Arjan Koers wrote:
>>> On 2010-10-03 01:42, Zachary Amsden wrote:
>>> ...
>>>> Umm...  do you guys have this commit?  This is supposed to address the
>>>> issue where the guest keeps resetting the TSC.  A guest which does that
>>>> will break kvmclock.  It only happens on SMP, and it's much worse on AMD
>>>> CPUs...
>>>>
>>>> sound like your scenario.
>>>>
>>>> commit bd59fc8ff95126f27b7a0df1b6cc602aa428812d
>>>> Author: Zachary Amsden<zamsden@redhat.com>
>>>> Date:   Thu Aug 19 22:07:26 2010 -1000
>>>
>>> This commit fixes the problem:
>>>
>>> commit aad07c4f92bae2edaa42bcef84c2afdd0d082458
>>> Author: Zachary Amsden<zamsden@redhat.com>
>>> Date:   Thu Aug 19 22:07:19 2010 -1000
>>>
>>>     KVM: x86: Move TSC reset out of vmcb_init
>>>
>>>     The VMCB is reset whenever we receive a startup IPI, so Linux is setting
>>>     TSC back to zero happens very late in the boot process and destabilizing
>>>     the TSC.  Instead, just set TSC to zero once at VCPU creation time.
>>>
>>>     Why the separate patch?  So git-bisect is your friend.
>>
>> Okay, apparently I need to go poke around 2.6.35 and see what
>> patches made it there and what patches didn't.
> 
> Backports attached. Michael, Arjan, please give them a try.
> 

Thanks for the patches.

Successfully tested with 2.6.34.7, 2.6.35.7 and 2.6.36-rc7 host
(with a 2.6.35.7 guest).

It failed with a 2.6.32.24 host. The patch applied, but
pvclock_clocksource_read on the guest is still producing wrong
results for CPU 1 while it's booting. I'll re-check tomorrow.