09 May, 2007

1 commit


02 May, 2007

1 commit

  • Currently, all 32-bit powerpc platforms use asm-ppc/pgtable.h and
    asm-ppc/pgalloc.h, even when otherwise compiled with ARCH=powerpc.
    Those asm-ppc files are a fairly nasty tangle of #ifdefs including a
    bunch of things which shouldn't be necessary any more in arch/powerpc.

    Cleaning up that mess is going to take a while, but this patch is a
    first step. It separates the asm-powerpc/pg{alloc,table}.h into 64
    bit and 32 bit versions in asm-powerpc, which the basic .h files in
    asm-powerpc select based on config. We make a few tiny tweaks to the
    innards of the files along the way, making the outermost ifdefs
    (double-inclusion protection and __KERNEL__) a little cleaner, and
    #including asm-generic/pgtable.h from the top-level
    asm-powerpc/pgtable.h (since both the old 32-bit and 64-bit versions
    ended with such an #include).

    Signed-off-by: David Gibson
    Signed-off-by: Paul Mackerras

    David Gibson
     

13 Apr, 2007

1 commit

  • Some drivers have resources that they want to be able to map into
    userspace that are 4k in size. On a kernel configured with 64k pages
    we currently end up mapping the 4k we want plus another 60k of
    physical address space, which could contain anything. This can
    introduce security problems, for example in the case of an infiniband
    adaptor where the other 60k could contain registers that some other
    program is using for its communications.

    This patch adds a new function, remap_4k_pfn, which drivers can use to
    map a single 4k page to userspace regardless of whether the kernel is
    using a 4k or a 64k page size. Like remap_pfn_range, it would
    typically be called in a driver's mmap function. It only maps a
    single 4k page, which on a 64k page kernel appears replicated 16 times
    throughout a 64k page. On a 4k page kernel it reduces to a call to
    remap_pfn_range.

    The way this works on a 64k kernel is that a new bit, _PAGE_4K_PFN,
    gets set on the linux PTE. This alters the way that __hash_page_4K
    computes the real address to put in the HPTE. The RPN field of the
    linux PTE becomes the 4k RPN directly rather than being interpreted as
    a 64k RPN. Since the RPN field is 32 bits, this means that physical
    addresses being mapped with remap_4k_pfn have to be below 2^44,
    i.e. 0x100000000000.

    The patch also factors out the code in arch/powerpc/mm/hash_utils_64.c
    that deals with demoting a process to use 4k pages into one function
    that gets called in the various different places where we need to do
    that. There were some discrepancies between exactly what was done in
    the various places, such as a call to spu_flush_all_slbs in one case
    but not in others.

    Signed-off-by: Paul Mackerras

    Paul Mackerras
     

15 Jun, 2006

1 commit

  • Some POWER5+ machines can do 64k hardware pages for normal memory but
    not for cache-inhibited pages. This patch lets us use 64k hardware
    pages for most user processes on such machines (assuming the kernel
    has been configured with CONFIG_PPC_64K_PAGES=y). User processes
    start out using 64k pages and get switched to 4k pages if they use any
    non-cacheable mappings.

    With this, we use 64k pages for the vmalloc region and 4k pages for
    the imalloc region. If anything creates a non-cacheable mapping in
    the vmalloc region, the vmalloc region will get switched to 4k pages.
    I don't know of any driver other than the DRM that would do this,
    though, and these machines don't have AGP.

    When a region gets switched from 64k pages to 4k pages, we do not have
    to clear out all the 64k HPTEs from the hash table immediately. We
    use the _PAGE_COMBO bit in the Linux PTE to indicate whether the page
    was hashed in as a 64k page or a set of 4k pages. If hash_page is
    trying to insert a 4k page for a Linux PTE and it sees that it has
    already been inserted as a 64k page, it first invalidates the 64k HPTE
    before inserting the 4k HPTE. The hash invalidation routines also use
    the _PAGE_COMBO bit, to determine whether to look for a 64k HPTE or a
    set of 4k HPTEs to remove. With those two changes, we can tolerate a
    mix of 4k and 64k HPTEs in the hash table, and they will all get
    removed when the address space is torn down.

    Signed-off-by: Paul Mackerras

    Paul Mackerras
     

09 Jan, 2006

1 commit

  • include/asm-ppc/ had #ifdef __KERNEL__ in all header files that
    are not meant for use by user space, include/asm-powerpc does
    not have this yet.

    This patch gets us a lot closer there. There are a few cases
    where I was not sure, so I left them out. I have verified
    that no CONFIG_* symbols are used outside of __KERNEL__
    any more and that there are no obvious compile errors when
    including any of the headers in user space libraries.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Paul Mackerras

    Arnd Bergmann
     

19 Nov, 2005

1 commit