Messages in this thread | | | Date | Tue, 30 Nov 2010 08:09:54 -1000 | From | Zachary Amsden <> | Subject | Re: linux-next: Tree for November 22 (kvm) |
| |
On 11/30/2010 02:17 AM, Glauber Costa wrote: > On Mon, 2010-11-29 at 08:08 -1000, Zachary Amsden wrote: > >> On 11/29/2010 07:52 AM, Randy Dunlap wrote: >> >>> On 11/29/10 09:47, Zachary Amsden wrote: >>> >>> >>>> On 11/29/2010 06:35 AM, Avi Kivity wrote: >>>> >>>> >>>>> On 11/29/2010 06:33 PM, Randy Dunlap wrote: >>>>> >>>>> >>>>>> On Mon, 22 Nov 2010 13:26:27 -0800 Randy Dunlap wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Mon, 22 Nov 2010 13:49:11 +1100 Stephen Rothwell wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Changes since 20101119: >>>>>>>> >>>>>>>> >>>>>>> kvm.c:(.init.text+0x11f49): undefined reference to >>>>>>> >>>>>>> >>>>>> `kvm_register_clock' >>>>>> >>>>>> >>>>>>> when CONFIG_KVM_CLOCK is not enabled. >>>>>>> >>>>>>> >>>>>> BUild error still present in linux-next-2010-NOV-29. >>>>>> >>>>>> >>>>>> >>>>> Glauber, Zach? >>>>> >>>>> >>>>> >>>> I can only speculate this reference is being called from smpboot without >>>> CONFIG guarding? >>>> >>>> >>> Sorry, looks like I dropped the first line of the error messages: >>> >>> 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... >>> >>> >> Looks like this is the appropriate fix: >> >> #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? >> > Can we identify precisely when it happens? If we can, we can try to > 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. >
It's as if we need a new type of per-cpu data, per_cpu_zeroed, which is always cleared prior to starting on the AP.
I imagine other code paths may need this as well.
Zach
| |