similar to: RE: recent major -unstable changes cause ia64 build to bebroken

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

# HG changeset patch # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1345135101 -7200 # Node ID 85190245a94d9945b7656c971ba36f7d1eff5c19 # Parent 6d56e31fe1e1dc793379d662a36ff1731760eb0c AMD, powernow: Update P-state directly when _PSD''s CoordType is DOMAIN_COORD_TYPE_HW_ALL When _PSD''s CoordType is DOMAIN_COORD_TYPE_HW_ALL (i.e. shared_type is

Patch 1 removes CONFIG_SMP Patch 2 removes separate smp_{,r,w}mb()s as a result of patch 1 Patch 4 removes __ia64__ defines from the x86 arch tree Patch 3 is related to patch 4 and changes the VIOAPIC to emulate version 0x20 as a performance gain. It preceeds Patch 4 so as to be more clear about the functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Currently cpufreq and xenpm are out of sync. Fix cpufreq reporting of if turbo mode is enabled or not. Fix xenpm to not decode for tristate, but a boolean. Signed-off-by: Jacob Shin <jacob.shin@amd.com> --- tools/misc/xenpm.c | 14 +++----------- xen/drivers/cpufreq/utility.c | 2 +- 2 files changed, 4 insertions(+), 12 deletions(-) diff --git a/tools/misc/xenpm.c

If stop_machine() invoked while one of onlined cpu is locked up by some reason, stop_machine cannot finish its work because the locked cpu cannot stop. This means all other healthy cpus will be blocked infinitely by one dead cpu. This patch allows stop_machine to return -EBUSY with some printk messages if any of stop_machine's threads cannot start running on its target cpu in time. You can

If stop_machine() invoked while one of onlined cpu is locked up by some reason, stop_machine cannot finish its work because the locked cpu cannot stop. This means all other healthy cpus will be blocked infinitely by one dead cpu. This patch allows stop_machine to return -EBUSY with some printk messages if any of stop_machine's threads cannot start running on its target cpu in time. You can

smp_call_function and smp_call_function_single are almost complete duplicates of the same logic. This patch combines them by implementing them in terms of the more general smp_call_function_mask(). [ Jan, Andi: This only changes arch/i386; can x86_64 be changed in the same way? ] [ Rebased onto Jan's x86_64-mm-consolidate-smp_send_stop patch ] Signed-off-by: Jeremy Fitzhardinge

smp_call_function and smp_call_function_single are almost complete duplicates of the same logic. This patch combines them by implementing them in terms of the more general smp_call_function_mask(). [ Jan, Andi: This only changes arch/i386; can x86_64 be changed in the same way? ] [ Rebased onto Jan's x86_64-mm-consolidate-smp_send_stop patch ] Signed-off-by: Jeremy Fitzhardinge

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

I am confused with a problem: I have a blade with 64 physical CPUs and 64G physical RAM, and defined only one VM with 1 CPU and 40G RAM. For the first time I started the VM, it just took 3s, But for the second starting it took 30s. After studied it by printing log, I have located a place in the hypervisor where cost too much time, occupied 98% of the whole starting time. xen/common/page_alloc.c

Hi Gonglei, [auto build test ERROR on cryptodev/master] [also build test ERROR on v4.9-rc7 next-20161202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gonglei/crypto-add-virtio-crypto-driver/20161202-190424 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master

Hi Gonglei, [auto build test ERROR on cryptodev/master] [also build test ERROR on v4.9-rc7 next-20161202] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gonglei/crypto-add-virtio-crypto-driver/20161202-190424 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master

Now that the scheduler can deal with migrate disable properly, there is no real compelling reason to make it only available for RT. There are quite some code pathes which needlessly disable preemption in order to prevent migration and some constructs like kmap_atomic() enforce it implicitly. Making it available independent of RT allows to provide a preemptible variant of kmap_atomic() and makes

Add Xen accessors for LDT updates. Todo: Bring back return values from write_ldt_entry. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/arch/i386/kernel/ldt.c =================================================================== --- linux-2.6.13.orig/arch/i386/kernel/ldt.c 2005-08-08 21:13:56.000000000 -0700 +++ linux-2.6.13/arch/i386/kernel/ldt.c 2005-08-08

Add Xen accessors for LDT updates. Todo: Bring back return values from write_ldt_entry. Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/arch/i386/kernel/ldt.c =================================================================== --- linux-2.6.13.orig/arch/i386/kernel/ldt.c 2005-08-08 21:13:56.000000000 -0700 +++ linux-2.6.13/arch/i386/kernel/ldt.c 2005-08-08

struct cpufreq_policy, including a cpumask_t member, gets copied in cpufreq_limit_change(), cpufreq_add_cpu(), set_cpufreq_gov(), and set_cpufreq_para(). Make the member a cpumask_var_t, thus reducing the amount of data needing copying (particularly with large NR_CPUS). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- 2011-09-20.orig/xen/arch/x86/acpi/cpufreq/cpufreq.c 2011-10-12

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

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