Re: 2.6.35-rc1 regression with pvclock and smp guests

Arjan Koers
2010-10-09T01:11:01Z

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.