From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: 2.6.35-rc1 regression with pvclock and smp guests Date: Sat, 31 Jul 2010 13:55:10 -1000 Message-ID: <4C54B7DE.4060901@redhat.com> References: <4C4D4B8B.80006@amd.com> <4C4DDB00.50203@xutrox.com> <4C4F48D0.8090609@xutrox.com> <4C500872.1020809@redhat.com> <4C536F80.5090205@xutrox.com> <4C538CCE.1010104@redhat.com> <4C540EC9.1010008@xutrox.com> <4C54512B.6000307@xutrox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Avi Kivity , Glauber Costa To: Arjan Koers <0h61vkll2ly8@xutrox.com> Return-path: Received: from mx1.redhat.com ([209.132.183.28]:42126 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753332Ab0GaXzP (ORCPT ); Sat, 31 Jul 2010 19:55:15 -0400 In-Reply-To: <4C54512B.6000307@xutrox.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/31/2010 06:36 AM, Arjan Koers wrote: > On 2010-07-31 13:53, Arjan Koers wrote: > >> The kernel boots successfully when CONFIG_PRINTK_TIME is not set. >> >> > The problem occurs when this message is printed: > > [ 0.016000] kvm-clock: cpu 1, msr 0:1511c01, secondary cpu clock > > When I disable that printk, the kernel boots with > CONFIG_PRINTK_TIME=y > > --- a/arch/x86/kernel/kvmclock.c > +++ b/arch/x86/kernel/kvmclock.c > @@ -131,8 +131,8 @@ static int kvm_register_clock(char *txt) > int low, high; > low = (int)__pa(&per_cpu(hv_clock, cpu)) | 1; > high = ((u64)__pa(&per_cpu(hv_clock, cpu))>> 32); > - printk(KERN_INFO "kvm-clock: cpu %d, msr %x:%x, %s\n", > - cpu, high, low, txt); > + /*printk(KERN_INFO "kvm-clock: cpu %d, msr %x:%x, %s\n", > + cpu, high, low, txt);*/ > > return native_write_msr_safe(msr_kvm_system_time, low, high); > } > > So the problem appears to be that the clock of the second CPU > is used too soon (or that clock setup should finish earlier). > That's almost hilarious. The printk from setting up the kvm clock is invoking the kvm clock before it is setup. There's no reason other printks couldn't do the same thing, however. I think it's safest to keep an initialized flag and check for it before attempting to return a meaningful value. Zach