On Mon, 2010-11-29 at 08:08 -1000, Zachary Amsden wrote:
On 11/29/2010 07:52 AM, Randy Dunlap wrote:Can we identify precisely when it happens? If we can, we can try to
On 11/29/10 09:47, Zachary Amsden wrote:Looks like this is the appropriate fix:
On 11/29/2010 06:35 AM, Avi Kivity wrote:Sorry, looks like I dropped the first line of the error messages:
On 11/29/2010 06:33 PM, Randy Dunlap wrote:I can only speculate this reference is being called from smpboot without
On Mon, 22 Nov 2010 13:26:27 -0800 Randy Dunlap wrote:Glauber, Zach?
On Mon, 22 Nov 2010 13:49:11 +1100 Stephen Rothwell wrote:`kvm_register_clock'
Hi all,kvm.c:(.init.text+0x11f49): undefined reference to
Changes since 20101119:
when CONFIG_KVM_CLOCK is not enabled.BUild error still present in linux-next-2010-NOV-29.
CONFIG guarding?
arch/x86/built-in.o: In function `kvm_smp_prepare_boot_cpu':
kvm.c:(.init.text+0xad38): undefined reference to `kvm_register_clock'
from arch/x86/kernel/kvm.c:
#ifdef CONFIG_SMP
static void __init kvm_smp_prepare_boot_cpu(void)
{
WARN_ON(kvm_register_clock("primary cpu clock"));
kvm_guest_cpu_init();
native_smp_prepare_boot_cpu();
}
so it looks like you are correct...
#ifdef CONFIG_SMP
static void __init kvm_smp_prepare_boot_cpu(void)
{
#ifdef CONFIG_KVM_CLOCK
WARN_ON(kvm_register_clock("primary cpu clock"));
#endif
kvm_guest_cpu_init();
native_smp_prepare_boot_cpu();
}
The SMP code is still buggy as well, wrt printk timing, in that it
doesn't get called early enough, correct? Has anyone thought of a good
solution to that problem?
Basically the problem is CPU-1 will get CPU-0's per-cpu areas copied
over, and these are not valid for CPU-1. If the clocksource is used on
CPU-1 before kvm clock gets setup, it can go backwards, wreaking havoc,
causing panic, etc.
What is the best test to guard against this? Perhaps we should keep the
CPU number in the per-cpu data and test against it?
force a hypervisor exit or re-register right after the data is copied
over. This will force the per-cpu structure to get updated with good
values.