search for: cpu_up

...he 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, +}; =================================================================== --- a/arch/i38...

...he 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, +}; =================================================================== --- a/arch/i38...

I'm sending a first draft of my proposed cpu hotplug driver for kvm/virtio The first patch is the kernel module, while the second, the userspace pci device. The host boots with the maximum cpus it should ever use, through the -smp parameter. Due to real machine constraints (which qemu copies), i386 does not allow for any addition of cpus after boot, so this is the most general way. I do

I'm sending a first draft of my proposed cpu hotplug driver for kvm/virtio The first patch is the kernel module, while the second, the userspace pci device. The host boots with the maximum cpus it should ever use, through the -smp parameter. Due to real machine constraints (which qemu copies), i386 does not allow for any addition of cpus after boot, so this is the most general way. I do

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

...e(); + 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,

...e(); + 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,

...MCI. And for supporting CPUs, still some banks don''t support CMCI. So we keep polling mechanism. 3) MCA banks shares between cores/threads. For avoiding mis-ops, we need to judge *owner* for each bank. Each bank only has one owner, the owner manages the bank. The owner will be set up when cpu_up. Owners might be changed when doing cpu-hotplug. 4) When one CMCI interrupt is accepted and logged by XEN, XEN will notify DOM0. We don''t plan to check in DOM0 code now. For more info, please refer to latest Intel software development manual, Chapter 14. --------------------------------...

...paging_mode_hap(v->domain) ) @@ -1527,7 +1522,6 @@ static struct hvm_function_table __read_ .inject_trap = vmx_inject_trap, .init_hypercall_page = vmx_init_hypercall_page, .event_pending = vmx_event_pending, - .do_pmu_interrupt = vmx_do_pmu_interrupt, .cpu_up = vmx_cpu_up, .cpu_down = vmx_cpu_down, .cpuid_intercept = vmx_cpuid_intercept, @@ -1642,7 +1636,7 @@ static void vmx_cpuid_intercept( { case 0x80000001: /* SYSCALL is visible iff running in long mode. */ - hvm_get_segme...

Just run into an odd DomU crash doing live migration of a 4-VCPU domain (with 3.0.4 but the code looks the same in 2.6.18/unstable to me) - the actual panic is attached at the end of this, but the bottom line is that the code in cache_remove_shared_cpu_map (in arch/i385/kernel/cpu/intel_cacheinfo.c) is attempting to clean up the cache info for a processor that does not yet have this info setup -

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

...>subtype ) { + case CMSG_VCPU_HOTPLUG_OFF: + handler->fn = (void *)&cpu_down; + ret = schedule_work(&vcpu_hotplug_work); + req->status = (u32) ret; + break; + case CMSG_VCPU_HOTPLUG_ON: + handler->fn = (void *)&cpu_up; + ret = schedule_work(&vcpu_hotplug_work); + req->status = (u32) ret; + break; + default: + goto parse_error; + } + + ctrl_if_send_response(msg); + return; + parse_error: + msg->length = 0; + ctrl_if_send_response(msg); +} + +...

...p_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...

...p_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 implements cpu offline feature. Best Regards Haitao Shan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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

Hi Konrad I encountered a bug when trying to bring offline a cpu then online it again in HVM. As I''m not very familiar with HVM stuffs I cannot come up with a quick fix. The HVM DomU is configured with 4 vcpus. After booting into command prompt, I do following operations. # echo 0 > /sys/devices/system/cpu/cpu3/online # echo 1 > /sys/devices/system/cpu/cpu3/online With

Hi Andi, This patch series implements the Linux Xen guest as a paravirt_ops backend. The features in implemented this patch series are: * domU only * UP and SMP guest support (NEW!) * dynamic ticks (NEW!) * writable pagetables, with late pinning/early unpinning (no shadow pagetable support) * supports both PAE and non-PAE modes (non-PAE may be broken at the moment) * xen hvc console