search for: __per_cpu_start

Hi Andi, This is a series of patches based on your latest queue (as of the other day, at least). It includes: - the most recent patch to compute the appropriate amount of percpu space to allocate, using a separate reservation for modules where needed. - make the percpu sections page-aligned, so that percpu variables can be page aligned if needed (which is used by gdt_page) -

Hi Andi, This is a series of patches based on your latest queue (as of the other day, at least). It includes: - the most recent patch to compute the appropriate amount of percpu space to allocate, using a separate reservation for modules where needed. - make the percpu sections page-aligned, so that percpu variables can be page aligned if needed (which is used by gdt_page) -

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

...har **); extern void late_setup_arch(char **); diff -r 010ae57673c7 -r 47e5627d8558 xen/arch/powerpc/setup.c --- a/xen/arch/powerpc/setup.c Wed Sep 20 21:47:29 2006 -0400 +++ b/xen/arch/powerpc/setup.c Thu Sep 21 00:52:18 2006 -0400 @@ -87,9 +87,6 @@ struct ns16550_defaults ns16550; extern char __per_cpu_start[], __per_cpu_data_end[], __per_cpu_end[]; -/* move us to a header file */ -extern void initialize_keytable(void); - volatile struct processor_area * volatile global_cpu_table[NR_CPUS]; int is_kernel_text(unsigned long addr) diff -r 010ae57673c7 -r 47e5627d8558 xen/arch/x86/setup.c --- a/xen/a...

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned

All, We met several system failures on different hardware platforms, which are all caused by VT-d fault. err 1: disk is corrupted by VT-d fault on SATA. err 2: Dom0 kernel panics at booting, which is caused VT-d fault on UHCI. err 3, Dom0 complains disk errors while creating HVM guests. The culprit would be changeset 19054 "x86_64: Remove statically-partitioned Xen heap.". Detailed

...ule.c 2005-06-17 21:48:29.000000000 +0200 -+++ linux-2.6.12-xen/kernel/module.c 2006-02-17 00:45:18.228522203 +0100 ++++ linux-2.6.12-xen/kernel/module.c 2006-02-25 00:12:33.769994548 +0100 @@ -249,13 +249,18 @@ static inline unsigned int block_size(in /* Created by linker magic */ extern char __per_cpu_start[], __per_cpu_end[]; @@ -103311,7 +103314,7 @@ goto free_mod; diff -Nurp pristine-linux-2.6.12/kernel/rcupdate.c linux-2.6.12-xen/kernel/rcupdate.c --- pristine-linux-2.6.12/kernel/rcupdate.c 2005-06-17 21:48:29.000000000 +0200 -+++ linux-2.6.12-xen/kernel/rcupdate.c 2006-02-17 00:45:18.26951...

Changes: - patch v3: - Update on message to describe longer term PIE goal. - Minor change on ftrace if condition. - Changed code using xchgq. - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends

Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See