search for: __cpu_up

When secondary cpus are initialized during an i386 pv-guest restore (due to save/restore or live migration), and the guest has a load that generates a fair number of interrupts (e.g., parallel kernel make), a stack overflow can occur because cpu_initialize_context() has a 2800 byte structure it declares on its stack. linux-i386 has 4K stacks, by default. Using 2800 bytes out of 4K by a single

...quot;r" (__KERNEL_PERCPU) : "memory"); } -void __init smp_prepare_boot_cpu(void) +void __init native_smp_prepare_boot_cpu(void) { unsigned int cpu = smp_processor_id(); @@ -1290,7 +1290,7 @@ void __cpu_die(unsigned int cpu) } #endif /* CONFIG_HOTPLUG_CPU */ -int __cpuinit __cpu_up(unsigned int cpu) +int __cpuinit native_cpu_up(unsigned int cpu) { unsigned long flags; #ifdef CONFIG_HOTPLUG_CPU @@ -1335,7 +1335,7 @@ int __cpuinit __cpu_up(unsigned int cpu) return 0; } -void __init smp_cpus_done(unsigned int max_cpus) +void __init native_smp_cpus_done(unsigned int max_...

...quot;r" (__KERNEL_PERCPU) : "memory"); } -void __init smp_prepare_boot_cpu(void) +void __init native_smp_prepare_boot_cpu(void) { unsigned int cpu = smp_processor_id(); @@ -1290,7 +1290,7 @@ void __cpu_die(unsigned int cpu) } #endif /* CONFIG_HOTPLUG_CPU */ -int __cpuinit __cpu_up(unsigned int cpu) +int __cpuinit native_cpu_up(unsigned int cpu) { unsigned long flags; #ifdef CONFIG_HOTPLUG_CPU @@ -1335,7 +1335,7 @@ int __cpuinit __cpu_up(unsigned int cpu) return 0; } -void __init smp_cpus_done(unsigned int max_cpus) +void __init native_smp_cpus_done(unsigned int max_...

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

...ts, and presumably the sibling relationships are useful in principle), but also a whole pile of APIC stuff which is irrelevent to Xen. It has these exported symbols, with my first pass comments: 00000644 T __cpu_die -- need pv_op 000008a5 T __cpu_disable -- need pv_op 000006aa T __cpu_up -- need pv_op 00000000 T cpu_coregroup_map -- ? ignore 00000868 T cpu_exit_clear -- ? 00000d9f T initialize_secondary -- Xen no-op 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 s...

...ts, and presumably the sibling relationships are useful in principle), but also a whole pile of APIC stuff which is irrelevent to Xen. It has these exported symbols, with my first pass comments: 00000644 T __cpu_die -- need pv_op 000008a5 T __cpu_disable -- need pv_op 000006aa T __cpu_up -- need pv_op 00000000 T cpu_coregroup_map -- ? ignore 00000868 T cpu_exit_clear -- ? 00000d9f T initialize_secondary -- Xen no-op 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 s...

...smp_prepare_boot_cpu(void) +{ + init_gdt(smp_processor_id()); + switch_to_new_gdt(); + cpu_set(smp_processor_id(), cpu_online_map); cpu_set(smp_processor_id(), cpu_callout_map); cpu_set(smp_processor_id(), cpu_possible_map); cpu_set(smp_processor_id(), cpu_present_map); } -int __devinit -__cpu_up(unsigned int cpu) +static int __devinit +voyager_cpu_up(unsigned int cpu) { /* This only works at boot for x86. See "rewrite" above. */ if (cpu_isset(cpu, smp_commenced_mask)) @@ -1956,8 +1958,8 @@ __cpu_up(unsigned int cpu) return 0; } -void __init -smp_cpus_done(unsigned int...

...smp_prepare_boot_cpu(void) +{ + init_gdt(smp_processor_id()); + switch_to_new_gdt(); + cpu_set(smp_processor_id(), cpu_online_map); cpu_set(smp_processor_id(), cpu_callout_map); cpu_set(smp_processor_id(), cpu_possible_map); cpu_set(smp_processor_id(), cpu_present_map); } -int __devinit -__cpu_up(unsigned int cpu) +static int __devinit +voyager_cpu_up(unsigned int cpu) { /* This only works at boot for x86. See "rewrite" above. */ if (cpu_isset(cpu, smp_commenced_mask)) @@ -1956,8 +1958,8 @@ __cpu_up(unsigned int cpu) return 0; } -void __init -smp_cpus_done(unsigned int...

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

I''m afraid this series is rather a grab bag and it is distressingly large at this stage. With this series I can boot an Xgene board until it fails to find its SATA controller. This is a dom0 issue for which patches are pending from APM (/me nudges Anup). As well as the APM specific platform stuff there are also some generic improvements which were either necessary or useful during this

Hi, This is the fifth version of this patch series. With the Versatile Express TC2, it''s possible to boot only with A7 or A15. If the user choose to boot with only A7, the CPU ID will start at 0x100. As Xen relies on it to set the logical ID and the GIC, it won''t be possible to use Xen with this use case. This patch series is divided in 3 parts: - Patch 1: prepare Xen

George has release acked all of these. Otherwise mostly minor updates this time around. Summary: A == acked, M == modified A xen: arm64: Add 8250 earlyprintk support A xen: arm64: Add Basic Platform support for APM X-Gene Storm. A xen: arm64: Add APM implementor id to processor implementers. M xen: arm: add a quirk to handle platforms with unusual GIC layout A xen: arm: allow platform

...; + timer_init(); early_time_init(); @@ -693,8 +696,10 @@ void __init __start_xen(multiboot_info_t { if ( num_online_cpus() >= max_cpus ) break; - if ( !cpu_online(i) ) + if ( !cpu_online(i) ) { + rcu_online_cpu(i); __cpu_up(i); + } /* Set up cpu_to_node[]. */ srat_detect_node(i); diff -r 895d873a00b4 -r fa213888aa93 xen/common/Makefile --- a/xen/common/Makefile Tue Jan 16 10:02:50 2007 +0000 +++ b/xen/common/Makefile Tue Jan 16 14:17:36 2007 -0800 @@ -28,6 +28,7 @@ obj-y += version.o obj-y...

...; + timer_init(); early_time_init(); @@ -693,8 +696,10 @@ void __init __start_xen(multiboot_info_t { if ( num_online_cpus() >= max_cpus ) break; - if ( !cpu_online(i) ) + if ( !cpu_online(i) ) { + rcu_online_cpu(i); __cpu_up(i); + } /* Set up cpu_to_node[]. */ srat_detect_node(i); diff -r 895d873a00b4 -r fa213888aa93 xen/common/Makefile --- a/xen/common/Makefile Tue Jan 16 10:02:50 2007 +0000 +++ b/xen/common/Makefile Tue Jan 16 14:17:36 2007 -0800 @@ -28,6 +28,7 @@ obj-y += version.o obj-y...

Hello, On my x86_64 box, when compiling the xen-3.0.4-rc1, if CONFIG_HOTPLUG_CPU is not set it produces an undefined reference to ''remove_siblinginfo'' that is used in arch/x86_64/kernel/smpboot.c drivers/built-in.o: In function `__cpu_up'': (.text+0x54c10): undefined reference to `remove_siblinginfo'' If CONFIG_HOTPLUG_CPU is set the compilation works fine. I paste my .config file at the end of the email. Hope this help, Guillaume # # Automatically generated make config: don''t edit # Linux kernel...

Hi, I''ve still have problems with ACPI(?) on Xen. After some system startup or resume CPU temperature goes high although all domUs (and dom0) are idle. On "good" system startup it is about 50-55C, on "bad" - above 67C (most time above 70C). I''ve noticed difference in C-states repored by Xen (attached files). On "bad" startups in addition suspend

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions which is necessary to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions which is necessary to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Please review and comments. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions