similar to: [PATCH] Simplify smp_call_function*() by using common implementation

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> --- arch/i386/kernel/Makefile | 1 arch/i386/kernel/smp.c

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> --- arch/i386/kernel/Makefile | 1 arch/i386/kernel/smp.c

From: Julien Grall <julien.grall@citrix.com> Move smp_call_function and on_selected_cpus to common code. Signed-off-by: Julien Grall <julien.grall@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Keir Fraser <keir@xen.org> --- Changes in V2: - Add copyright header in xen/common/smp.c xen/arch/arm/gic.c | 3 ++ xen/arch/arm/smp.c

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

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 implemented unconditionally since it is simpler that way and not a highly performance-sensitive

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 implemented unconditionally since it is simpler that way and not a highly performance-sensitive

Short of getting an explanation for the odd difference to native, make the code match native (and also, in the case of x86-64, __smp_call_function_single()). As usual, written and tested against 2.6.24-rc3 and made apply against 2.6.18 without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2007-11-30/arch/i386/kernel/smp-xen.c

Zhang, Xiantao wrote: > > diff --git a/include/linux/smp.h b/include/linux/smp.h > index 55232cc..b71820b 100644 > --- a/include/linux/smp.h > +++ b/include/linux/smp.h > @@ -56,6 +56,9 @@ int smp_call_function(void(*func)(void *info), void > *info, int retry, int wait); > > int smp_call_function_single(int cpuid, void (*func) (void *info), void > *info, >

Zhang, Xiantao wrote: >>From 697d50286088e98da5ac8653c80aaa96c81abf87 Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <xiantao.zhang at intel.com> > Date: Mon, 31 Mar 2008 09:50:24 +0800 > Subject: [PATCH] KVM:IA64: Implement smp_call_function_mask for ia64 > > This function provides more flexible interface for smp > infrastructure. > Signed-off-by: Xiantao Zhang

Zhang, Xiantao wrote: >>From 697d50286088e98da5ac8653c80aaa96c81abf87 Mon Sep 17 00:00:00 2001 > From: Xiantao Zhang <xiantao.zhang at intel.com> > Date: Mon, 31 Mar 2008 09:50:24 +0800 > Subject: [PATCH] KVM:IA64: Implement smp_call_function_mask for ia64 > > This function provides more flexible interface for smp > infrastructure. > Signed-off-by: Xiantao Zhang

Hello all, I am working on adding atomics support to the AVR backend. Because the target can only have one core, it is sufficient to: - Save the status register - Disable interrupts - Do the nonatomic LOAD/STORE/SWAP/ADD - Restore the status register I’d really like to be able to do this at the IR level. What I want to do is write a custom lowering hook to convert ISD::ATOMIC_LOAD

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

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

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

On Tue, Apr 05, 2016 at 07:10:04AM +0200, Juergen Gross wrote: > +int smp_call_on_cpu(unsigned int cpu, bool pin, int (*func)(void *), void *par) Why .pin and not .phys? .pin does not (to me) reflect the hypervisor/physical-cpu thing. Also, as per smp_call_function_single() would it not be more consistent to make this the last argument? > +{ > + struct smp_call_on_cpu_struct sscs = {

On Tue, Apr 05, 2016 at 07:10:04AM +0200, Juergen Gross wrote: > +int smp_call_on_cpu(unsigned int cpu, bool pin, int (*func)(void *), void *par) Why .pin and not .phys? .pin does not (to me) reflect the hypervisor/physical-cpu thing. Also, as per smp_call_function_single() would it not be more consistent to make this the last argument? > +{ > + struct smp_call_on_cpu_struct sscs = {

My experience with LLVM is limited, but I am trying to figure out how to add optimizations for automatic reference counting. The GC documentation mentions that patch-points could be useful, but it does not state how they would be useful. If this is a FAQ, please let me know... So this is my idea at this point: The context is a C++ like language with an aggregate type that is always reference

The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Suggested-by: Geert Uytterhoeven <geert at linux-m68k.org>

Hi, Multiple architectures are affected in the first patch and all further patches depend on the first. Maybe this could go in through Andrew Morton's tree? Changes since v2 ================ 1. Drop all non-essential patches (cleanups), 2. Update also drivers/sh/clk/cpg.c . Changes since v1 ================ https://lore.kernel.org/lkml/1578415992-24054-1-git-send-email-krzk at