Re: 2.6.35-rc1 regression with pvclock and smp guests

[Zachary Amsden <zamsden@redhat.com>]

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