[Xen-devel] [PATCH 0 of 13] Basic infrastructure patches for a paravirtualized kernel

[Jeremy Fitzhardinge <jeremy@xxxxxxxxxxxxx>]

[ REPOST: Apologies to anyone who has seen this before.  It
  didn't make it onto any of the lists it should have. -J ]

Hi Andrew,

This series of patches lays the basic ground work for the
paravirtualized kernel patches coming later on.  I think this lot is
ready for the rough-and-tumble world of the -mm tree.

For the most part, these patches do nothing or very little.  The
patches should be self explanatory, but the overview is:

Helper functions for later use:
        1/13: Add apply_to_page_range()...
        3/13: Implement always-locked bit ops...
        13/13: Put .note.* sections into a PT_NOTE segment in vmlinux

Cleanups:
        2/13: Remove locally-defined ldt structure in favour of standard type
        4/13: Allow a kernel to not be in ring 0
        6/13: Roll all the cpuid asm into one __cpuid call
        9/13: Remove the read hazard from the COW path in copy_one_pte
        10/13: Change pte_clear_full to a more appropriately named...

Hooks:
        5/13: Replace sensitive instructions with macros
        7/13: Make __FIXADDR_TOP variable to allow it to make space...
        8/13: Add a bootparameter to reserve high linear address...
        11/13: Add lazy MMU mode hooks for batching PTE updates
        12/13: Pass the mm struct into the pgd_free code so the mm...


Probably the most subtle changes here are 11/13 and 9/13, since they
add a new constraint to page-table manipulation code.  In a
paravirtualized system, pte updates may be batched and performed
lazily, so their effects will not be immediately visible on the pte
itself.  To avoid this, code which modifies ptes in a loop needs to
avoid looking at the modified ptes.  9/13 fixes the one place where it
happens.

11/13 depends on removing these read hazards for correctness when running
under a direct page table hypervisor which batches updates.  However, it
is generally agreed that using an _explicit_, rather than an _implicit_
notion of batching makes it easy to find and reason about the paths which
are doing batching.  This allows easy inspection to remove read hazards
from the code.

13/13 "Put .note.* sections into a PT_NOTE segment in vmlinux" is
mostly here to shake out problems early.  It slightly changes the way
the vmlinux image is linked together, and it uses the somewhat
esoteric PHDRS command in vmlinux.lds.  I want to make sure that this
doesn't provoke any problems in the various binutils people are using.

Thanks,
        J

30 files changed, 609 insertions(+), 92 deletions(-)
arch/i386/Kconfig                 |    1 
arch/i386/kernel/entry.S          |   43 +++++-----
arch/i386/kernel/process.c        |    2 
arch/i386/kernel/reboot.c         |   12 --
arch/i386/kernel/setup.c          |   13 +++
arch/i386/kernel/vmlinux.lds.S    |   12 ++
arch/i386/mm/extable.c            |    2 
arch/i386/mm/fault.c              |   11 --
arch/i386/mm/init.c               |   42 +++++++++
arch/i386/mm/pgtable.c            |   21 ++++
include/asm-generic/pgtable.h     |   24 +++++
include/asm-generic/vmlinux.lds.h |    3 
include/asm-i386/fixmap.h         |    7 +
include/asm-i386/page.h           |    2 
include/asm-i386/pgalloc.h        |    4 
include/asm-i386/pgtable.h        |    1 
include/asm-i386/processor.h      |   74 ++++++++---------
include/asm-i386/ptrace.h         |    5 -
include/asm-i386/segment.h        |   10 ++
include/asm-i386/spinlock.h       |    7 +
include/asm-i386/sync_bitops.h    |  156 +++++++++++++++++++++++++++++++++++++
include/asm-i386/system.h         |   36 ++++++++
include/linux/elfnote.h           |   88 ++++++++++++++++++++
include/linux/mm.h                |    9 ++
kernel/fork.c                     |    2 
mm/fremap.c                       |    2 
mm/memory.c                       |  106 ++++++++++++++++++++++++-
mm/mprotect.c                     |    2 
mm/mremap.c                       |    2 
mm/msync.c                        |    2 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel