search for: smp_prepare_cpus

...se 3.0 guests seem to hang for me while 2.6.38 or older kernels were ok. After digging deeply into this, I think I found the issue. However, if that is true, it seems rather lucky if pv spinlocks in HVM worked for anybody. The xen_hvm_smp_init() call will change the smp_ops hooks. One of which is smp_prepare_cpus. This is done in start_kernel and at this point in time, there is no change to the pv_lock_ops and they point to the ticket versions. Later in start_kernel, check_bugs is called and part of that takes the pv_lock_ops and patches the kernel with the correct jumps. _After_ that, the kernel_init is ca...

...send_stop(void) { /* Don't deadlock on the call lock in panic */ int nolock = !spin_trylock(&call_lock); @@ -733,3 +733,14 @@ int safe_smp_processor_id(void) return cpuid >= 0 ? cpuid : 0; } + +struct smp_ops smp_ops = { + .smp_prepare_boot_cpu = native_smp_prepare_boot_cpu, + .smp_prepare_cpus = native_smp_prepare_cpus, + .cpu_up = native_cpu_up, + .smp_cpus_done = native_smp_cpus_done, + + .smp_send_stop = native_smp_send_stop, + .smp_send_reschedule = native_smp_send_reschedule, + .smp_call_function_mask = native_smp_call_function_mask, +}; =============================================...

...send_stop(void) { /* Don't deadlock on the call lock in panic */ int nolock = !spin_trylock(&call_lock); @@ -733,3 +733,14 @@ int safe_smp_processor_id(void) return cpuid >= 0 ? cpuid : 0; } + +struct smp_ops smp_ops = { + .smp_prepare_boot_cpu = native_smp_prepare_boot_cpu, + .smp_prepare_cpus = native_smp_prepare_cpus, + .cpu_up = native_cpu_up, + .smp_cpus_done = native_smp_cpus_done, + + .smp_send_stop = native_smp_send_stop, + .smp_send_reschedule = native_smp_send_reschedule, + .smp_call_function_mask = native_smp_call_function_mask, +}; =============================================...

Hi folks, Here is the result of the latest work on the pvops front, after the x86 arch merge. From the functionality point of view, almost nothing was changed, except for proper vsmp support - which was discussed, but not implemented before - and the introduction of smp_ops in x86_64, which eased the merging of the smp header. Speaking of the merge, a significant part (although not majority) of

Hi folks, Here is the result of the latest work on the pvops front, after the x86 arch merge. From the functionality point of view, almost nothing was changed, except for proper vsmp support - which was discussed, but not implemented before - and the introduction of smp_ops in x86_64, which eased the merging of the smp header. Speaking of the merge, a significant part (although not majority) of

...g System Research Center AMD Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> diff -r 49ffe9ef67d4 drivers/xen/core/smpboot.c --- a/drivers/xen/core/smpboot.c Fri Feb 29 10:29:13 2008 +0000 +++ b/drivers/xen/core/smpboot.c Fri Feb 29 12:54:47 2008 -0600 @@ -276,7 +276,8 @@ void __init smp_prepare_cpus(unsigned in cpu_2_logical_apicid[0] = 0; x86_cpu_to_apicid[0] = 0; - set_x86_acpiid_to_apicid(0, 0); + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) + set_x86_acpiid_to_apicid(0, 0); current_thread_info()->cpu = 0; @@ -325,7 +326,8 @@ void __init smp_prepare_cpus(unsigned in...

This patch series implements SMP boot for arch/arm, as far as getting all CPUs up and running the idle loop. Changes from v1: - moved barriers out of loop in udelay() - dropped broken GIC change in favour of explanatory comment - made the increment of ready_cpus atomic (I couldn''t move the increment to before signalling the next CPU because the PT switch has to happen between

.../mshyperv.c > index 1bf57d310f78..7522cae02759 100644 > --- a/arch/x86/kernel/cpu/mshyperv.c > +++ b/arch/x86/kernel/cpu/mshyperv.c > @@ -203,6 +203,31 @@ static void __init hv_smp_prepare_boot_cpu(void) > hv_init_spinlocks(); > #endif > } > + > +static void __init hv_smp_prepare_cpus(unsigned int max_cpus) > +{ > +#if defined(CONFIG_X86_64) I think it makes little sense to try to make Linux work as Hyper-V root partition when !CONFIG_X86_64. If we still care about Hyper-V enablement for !CONFIG_X86_64 we can probably introduce something like CONFIG_HYPERV_ROOT and enable...

...000008ee T smp_alloc_memory -- Xen no-op (doesn't matter if it gets called) 00000057 T smp_cpus_done -- unwanted for Xen 00000015 T smp_intr_init -- need something to set up IPIs, but APIC independent 0000082a T smp_prepare_boot_cpu -- looks OK for Xen, I think 00000066 T smp_prepare_cpus -- need pv_op So at first pass, it looks like we need 6-8 new pv_ops for SMP, which isn't very appealing. Any thoughts about how to come up with a more elegant interface? I'm digging through smpboot.c and friends, but there's a lot of goo in there... It's not clear to...

...n UP mode since it finds the local APIC disabled in bios. However, the xen based kernel tries to come up MP and fails in a non-intuitive way by hitting a BUG in the hypervisor code. Following is the stack trace of the xen based kernel: [<ff10f8d6>] alloc_vcpu+0x36/0x120 [<ff1518c0>] smp_prepare_cpus+0x460/0xd30 [<ff132fcd>] intel_p6_mcheck_init+0xbd/0xe0 [<ff1555b4>] get_mtrr_state+0xf4/0x110 [<ff1508f1>] __start_xen+0x5d1/0x9e0 [<ff123270>] new_tlbflush_clock_period+0x0/0x90 [<ff10015a>] start_paging+0x52/0x54 CPU0 FATAL TRAP 6 (invalid opcode), ERROR...

...- wmb(); /* make sure everything is out */ } static void __cpuinit cpu_bringup_and_idle(void) { - cpu_bringup(); - cpu_idle(); + smpboot_start_secondary(NULL); } static int xen_smp_intr_init(unsigned int cpu) @@ -515,6 +500,8 @@ static const struct smp_ops xen_smp_ops __initconst = { .smp_prepare_cpus = xen_smp_prepare_cpus, .smp_cpus_done = xen_smp_cpus_done, + .cpu_pre_starting = xen_cpu_pre_starting, + .cpu_up = xen_cpu_up, .cpu_die = xen_cpu_die, .cpu_disable = xen_cpu_disable,

...000008ee T smp_alloc_memory -- Xen no-op (doesn't matter if it gets called) 00000057 T smp_cpus_done -- unwanted for Xen 00000015 T smp_intr_init -- need something to set up IPIs, but APIC independent 0000082a T smp_prepare_boot_cpu -- looks OK for Xen, I think 00000066 T smp_prepare_cpus -- need pv_op So at first pass, it looks like we need 6-8 new pv_ops for SMP, which isn't very appealing. Any thoughts about how to come up with a more elegant interface? I'm digging through smpboot.c and friends, but there's a lot of goo in there... It's not clear to...

...- wmb(); /* make sure everything is out */ } static void __cpuinit cpu_bringup_and_idle(void) { - cpu_bringup(); - cpu_idle(); + smpboot_start_secondary(NULL); } static int xen_smp_intr_init(unsigned int cpu) @@ -515,6 +500,8 @@ static const struct smp_ops xen_smp_ops __initconst = { .smp_prepare_cpus = xen_smp_prepare_cpus, .smp_cpus_done = xen_smp_cpus_done, + .cpu_pre_starting = xen_cpu_pre_starting, + .cpu_up = xen_cpu_up, .cpu_die = xen_cpu_die, .cpu_disable = xen_cpu_disable,

...or_id(void) } /* broadcast a halt to all other CPUs */ -void -smp_send_stop(void) +static void +voyager_smp_send_stop(void) { smp_call_function(smp_stop_cpu_function, NULL, 1, 1); } @@ -1924,23 +1923,26 @@ smp_voyager_power_off(void *dummy) smp_stop_cpu_function(NULL); } -void __init -smp_prepare_cpus(unsigned int max_cpus) +static void __init +voyager_smp_prepare_cpus(unsigned int max_cpus) { /* FIXME: ignore max_cpus for now */ smp_boot_cpus(); } -void __devinit smp_prepare_boot_cpu(void) -{ +static void __devinit voyager_smp_prepare_boot_cpu(void) +{ + init_gdt(smp_processor_id()); +...

...or_id(void) } /* broadcast a halt to all other CPUs */ -void -smp_send_stop(void) +static void +voyager_smp_send_stop(void) { smp_call_function(smp_stop_cpu_function, NULL, 1, 1); } @@ -1924,23 +1923,26 @@ smp_voyager_power_off(void *dummy) smp_stop_cpu_function(NULL); } -void __init -smp_prepare_cpus(unsigned int max_cpus) +static void __init +voyager_smp_prepare_cpus(unsigned int max_cpus) { /* FIXME: ignore max_cpus for now */ smp_boot_cpus(); } -void __devinit smp_prepare_boot_cpu(void) -{ +static void __devinit voyager_smp_prepare_boot_cpu(void) +{ + init_gdt(smp_processor_id()); +...

...e_cpu ( cpu ) { struct privop_addr_count *v = per_cpu(privop_addr_counter, cpu); int i, j; --- 2009-07-10.orig/xen/arch/ia64/xen/xensetup.c 2009-07-10 08:51:30.000000000 +0200 +++ 2009-07-10/xen/arch/ia64/xen/xensetup.c 2009-07-15 10:01:13.000000000 +0200 @@ -606,8 +606,7 @@ skip_move: smp_prepare_cpus(max_cpus); /* We aren''t hotplug-capable yet. */ - for_each_cpu ( i ) - cpu_set(i, cpu_present_map); + cpus_or(cpu_present_map, cpu_present_map, cpu_possible_map); /* Enable IRQ to receive IPI (needed for ITC sync). */ local_irq_enable(); --- 2009-07-10.ori...

The current paravirt startup_ipi hook for vmware commit: ae5da273fe3352febd38658d8d34484cbcfb3423 is quite frankly ridiculous. In the middle of wake_up_secondary_cpu: We have: /* * Paravirt / VMI wants a startup IPI hook here to set up the * target processor state. */ startup_ipi_hook(phys_apicid, (unsigned long) start_secondary, (unsigned

The current paravirt startup_ipi hook for vmware commit: ae5da273fe3352febd38658d8d34484cbcfb3423 is quite frankly ridiculous. In the middle of wake_up_secondary_cpu: We have: /* * Paravirt / VMI wants a startup IPI hook here to set up the * target processor state. */ startup_ipi_hook(phys_apicid, (unsigned long) start_secondary, (unsigned

...0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<ffff8300001180f4>] __bug+0x24/0x30 (XEN) [<ffff830000106f15>] alloc_vcpu+0x45/0x130 (XEN) [<ffff830000107369>] alloc_idle_vcpu+0x59/0x80 (XEN) [<ffff830000169f49>] smp_prepare_cpus+0x4a9/0xd10 (XEN) [<ffff830000168f0c>] __start_xen+0x75c/0xac0 (XEN) [<ffff8300001001c1>] __high_start+0x94/0x96 (XEN) (XEN) ************************************ (XEN) CPU0 FATAL TRAP 6 (invalid opcode), ERROR_CODE 0000, IN INTERRUPT CONTEXT. (XEN) System shutting down -- need man...

...) - cumulative variable type changed (int ==> u32) in add_stat (Konrad) - remove unneeded kvm_guest_init for !CONFIG_KVM_GUEST case Changes in V3: - rebased to 3.2-rc1 - use halt() instead of wait for kick hypercall. - modify kick hyper call to do wakeup halted vcpu. - hook kvm_spinlock_init to smp_prepare_cpus call (moved the call out of head##.c). - fix the potential race when zero_stat is read. - export debugfs_create_32 and add documentation to API. - use static inline and enum instead of ADDSTAT macro. - add barrier() in after setting kick_vcpu. - empty static inline function for kvm_spinlock_init....