search for: smp_op

Add a smp_ops interface. This abstracts the API defined by <linux/smp.h> for use within arch/i386. The primary intent is that it be used by a paravirtualizing hypervisor to implement SMP, but it could also be used by non-APIC-using sub-architectures. This is related to CONFIG_PARAVIRT, but is implement...

Add a smp_ops interface. This abstracts the API defined by <linux/smp.h> for use within arch/i386. The primary intent is that it be used by a paravirtualizing hypervisor to implement SMP, but it could also be used by non-APIC-using sub-architectures. This is related to CONFIG_PARAVIRT, but is implement...

...sted patches) and even with those 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 j...

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 this work is merging things that was not possible before, due to the lack of paravirt for x86_64. What was done then, can be thought as a "lookahead-merge", which i...

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 this work is merging things that was not possible before, due to the lack of paravirt for x86_64. What was done then, can be thought as a "lookahead-merge", which i...

This adds an smp_ops for voyager, and hooks things up appropriately. This is the first baby-step to making subarch runtime switchable. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Eric W. Biederman <ebiederm@xmission.com>...

This adds an smp_ops for voyager, and hooks things up appropriately. This is the first baby-step to making subarch runtime switchable. Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Eric W. Biederman <ebiederm@xmission.com>...

From: Jon Medhurst <tixy@linaro.org> Add a new ''smp_init'' hook to machine_desc so platforms can specify a function to be used to setup smp ops instead of having a statically defined value. The hook must return true when smp_ops are initialized. If false the static mdesc->smp_ops will be used by default. Signed-off-by: Jon Medhurst <tixy@linaro.org> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: Santosh Shilimk...

...ruct pv_apic_ops pv_apic_ops; extern struct pv_mmu_ops pv_mmu_ops; extern struct pv_lock_ops pv_lock_ops; diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h index 222a6a3..c16ddf9 100644 --- a/arch/x86/include/asm/smp.h +++ b/arch/x86/include/asm/smp.h @@ -74,9 +74,6 @@ struct smp_ops { extern void set_cpu_sibling_map(int cpu); #ifdef CONFIG_SMP -#ifndef CONFIG_PARAVIRT -#define startup_ipi_hook(phys_apicid, start_eip, start_esp) do { } while (0) -#endif extern struct smp_ops smp_ops; static inline void smp_send_stop(void) diff --git a/arch/x86/kernel/paravirt.c b/arch/...

...ruct pv_apic_ops pv_apic_ops; extern struct pv_mmu_ops pv_mmu_ops; extern struct pv_lock_ops pv_lock_ops; diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h index 222a6a3..c16ddf9 100644 --- a/arch/x86/include/asm/smp.h +++ b/arch/x86/include/asm/smp.h @@ -74,9 +74,6 @@ struct smp_ops { extern void set_cpu_sibling_map(int cpu); #ifdef CONFIG_SMP -#ifndef CONFIG_PARAVIRT -#define startup_ipi_hook(phys_apicid, start_eip, start_esp) do { } while (0) -#endif extern struct smp_ops smp_ops; static inline void smp_send_stop(void) diff --git a/arch/x86/kernel/paravirt.c b/arch/...

Split xen_guest_init in two functions, one of them (xen_early_init) is going to be called very early from setup_arch. Change machine_desc->smp_init to xen_smp_init if Xen is present on the platform. xen_smp_init just sets smp_ops to psci_smp_ops. XEN selects ARM_PSCI. This patch is based on "xen/arm: move to mach-virt and support SMP" (http://marc.info/?l=linux-kernel&m=136629656432231&w=2) and "arm: introduce psci_smp_ops" (http://marc.info/?l=linux-kernel&m=136629750732674&w=2). A g...

...re are no gaps? (or we could've just used 'i')? > + BUG_ON(ret); > + } > +#endif > +} > #endif > > static void __init ms_hyperv_init_platform(void) > @@ -359,6 +384,8 @@ static void __init ms_hyperv_init_platform(void) > > # ifdef CONFIG_SMP > smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu; > + if (hv_root_partition) > + smp_ops.smp_prepare_cpus = hv_smp_prepare_cpus; > # endif > > /* -- Vitaly

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

...t here, the VCPU was woken up again. Jump to CPU + * startup code to get it back online. + */ + + start_cpu(); +} +#else /* CONFIG_HOTPLUG_CPU */ +#define sev_es_play_dead native_play_dead +#endif /* CONFIG_HOTPLUG_CPU */ + +#ifdef CONFIG_SMP +static void __init sev_es_setup_play_dead(void) +{ + smp_ops.play_dead = sev_es_play_dead; +} +#else +static inline void sev_es_setup_play_dead(void) { } +#endif + static void __init sev_es_alloc_runtime_data(int cpu) { struct sev_es_runtime_data *data; @@ -540,6 +596,8 @@ void __init sev_es_init_vc_handling(void) sev_es_setup_vc_stack(cpu); } +...

...ot;up". */ - local_irq_enable(); - - 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,

...ot;up". */ - local_irq_enable(); - - 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,

Paravirt ops is currently only capable of either replacing a lot of Linux internal code or none at all. The are users that don't need all of the possibilities pv-ops delivers though. On KVM for example we're perfectly fine not using the PV MMU, thus not touching any MMU code. That way we don't have to improve pv-ops to become fast, we just don't compile the MMU parts in! This

Paravirt ops is currently only capable of either replacing a lot of Linux internal code or none at all. The are users that don't need all of the possibilities pv-ops delivers though. On KVM for example we're perfectly fine not using the PV MMU, thus not touching any MMU code. That way we don't have to improve pv-ops to become fast, we just don't compile the MMU parts in! This

Guys currently I am horrified by the ease at which I can find bugs in the pending paravirtualization patches. I have barely even looked at arch/i386 in the -mm tree and it feels like I am tripping over significant bugs left and right. Because no one has heeded my advice and put in a proper platform layer on arch/i386 and we are instead doing a half baked job with paravirt_ops it is still