similar to: [PATCH 0/5] Virtualization patches, set 4

On Thu, 16 Nov 2006 00:16:26 +0100 Adrian Bunk <bunk@stusta.de> wrote: > Paravirt breaks CONFIG_X86_PAE=y compilation: > > <-- snip --> > > ... > CC init/main.o > In file included from include2/asm/pgtable.h:245, > from > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40, > from >

On Thu, 16 Nov 2006 00:16:26 +0100 Adrian Bunk <bunk@stusta.de> wrote: > Paravirt breaks CONFIG_X86_PAE=y compilation: > > <-- snip --> > > ... > CC init/main.o > In file included from include2/asm/pgtable.h:245, > from > /home/bunk/linux/kernel-2.6/linux-2.6.19-rc5-mm2/include/linux/mm.h:40, > from >

So it's gotten a bit confusing to figure out how we should go about upstreaming the rest of our patches. Our patchkit in the paravirt-ops tree currently applies to 2.6.19-rc4-mm2, but there are a number of conflicts that got resolved when merging into Andi's i386 tree. What is the best way to sanitize the remaining patches so they smoothly integrate into the appropriate trees?

So it's gotten a bit confusing to figure out how we should go about upstreaming the rest of our patches. Our patchkit in the paravirt-ops tree currently applies to 2.6.19-rc4-mm2, but there are a number of conflicts that got resolved when merging into Andi's i386 tree. What is the best way to sanitize the remaining patches so they smoothly integrate into the appropriate trees?

* zach@vmware.com (zach@vmware.com) wrote: > This code is quite dead. Release_thread is always guaranteed that the mm has > already been released, thus dead_task->mm will always be NULL. > > Signed-off-by: Zachary Amsden <zach@vmware.com> > Index: linux-2.6.13/arch/i386/kernel/process.c > =================================================================== > ---

* zach@vmware.com (zach@vmware.com) wrote: > This code is quite dead. Release_thread is always guaranteed that the mm has > already been released, thus dead_task->mm will always be NULL. > > Signed-off-by: Zachary Amsden <zach@vmware.com> > Index: linux-2.6.13/arch/i386/kernel/process.c > =================================================================== > ---

Hello, Here is my first speedup patch. Like 10-11%. No IDCT yet. Please feel free to comment my code or even better think about improvements. :) I belive my routines are not so bad, maybe one day they will be even more faster. What needs to be optimized is the loop filter fuction. I have no ideas now how to do it. It does not leave much space for parallel stuff, copying memory from lot of

Add some convenient descriptor access functions and move them all into desc.h Patch-base: 2.6.13-rc5-mm1 Patch-keys: i386 desc cleanup Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/include/asm-i386/desc.h =================================================================== --- linux-2.6.13.orig/include/asm-i386/desc.h 2005-08-09 19:43:38.000000000 -0700 +++

Add some convenient descriptor access functions and move them all into desc.h Patch-base: 2.6.13-rc5-mm1 Patch-keys: i386 desc cleanup Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/include/asm-i386/desc.h =================================================================== --- linux-2.6.13.orig/include/asm-i386/desc.h 2005-08-09 19:43:38.000000000 -0700 +++

On Mon, Aug 15, 2005 at 04:00:39PM -0700, zach@vmware.com wrote: > Make the generic version of ptep_set_wrprotect a macro. This is good for > code uniformity, and fixes the build for architectures which include pgtable.h > through headers into assembly code, but do not define a ptep_set_wrprotect > function. This against the kernel coding style. In fact, we are usually doing

On Mon, Aug 15, 2005 at 04:00:39PM -0700, zach@vmware.com wrote: > Make the generic version of ptep_set_wrprotect a macro. This is good for > code uniformity, and fixes the build for architectures which include pgtable.h > through headers into assembly code, but do not define a ptep_set_wrprotect > function. This against the kernel coding style. In fact, we are usually doing

SYSLINUX 3.11-pre5 is hereby a bug fix release candidate. If I don't receive any problem reports, I will release it as-is on Tuesday, August 30. http://www.kernel.org/pub/linux/utils/boot/syslinux/Testing/ -hpa

The per-CPU initialization code is copying in bogus data into thread->tls_array. Note that it copies &per_cpu(cpu_gdt_table, cpu), not &per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_TLS_MIN). That is totally broken and unnecessary. Make the initialization explicitly NULL. Signed-off-by: Zachary Amsden <zach@vmware.com Index: linux-2.6.13/include/asm-i386/processor.h

The per-CPU initialization code is copying in bogus data into thread->tls_array. Note that it copies &per_cpu(cpu_gdt_table, cpu), not &per_cpu(cpu_gdt_table, cpu)[GDT_ENTRY_TLS_MIN). That is totally broken and unnecessary. Make the initialization explicitly NULL. Signed-off-by: Zachary Amsden <zach@vmware.com Index: linux-2.6.13/include/asm-i386/processor.h

Fix paravirt_probe() macro so that handing it start_kernel doesn't evoke a warning (start_kernel is asmlinkage). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/dontdiff --minimal linux-2.6.19-rc4-mm2/include/asm-i386/paravirt.h working-2.6.19-rc4-mm2-warnings/include/asm-i386/paravirt.h ---

Fix paravirt_probe() macro so that handing it start_kernel doesn't evoke a warning (start_kernel is asmlinkage). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/dontdiff --minimal linux-2.6.19-rc4-mm2/include/asm-i386/paravirt.h working-2.6.19-rc4-mm2-warnings/include/asm-i386/paravirt.h ---

Chris Wright wrote: >* Zachary Amsden (zach@vmware.com) wrote: > > >>Does Xen assume page aligned descriptor tables? I assume from this >> >> > >Yes. > > > >>patch and snippets I have gathered from others, that is a yes, and other >>things here imply that DT pages are not shadowed. If so, Xen itself >>must have live segments

Chris Wright wrote: >* Zachary Amsden (zach@vmware.com) wrote: > > >>Does Xen assume page aligned descriptor tables? I assume from this >> >> > >Yes. > > > >>patch and snippets I have gathered from others, that is a yes, and other >>things here imply that DT pages are not shadowed. If so, Xen itself >>must have live segments

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