)]}'
{
  "log": [
    {
      "commit": "fa28237cfcc5827553044cbd6ee52e33692b0faa",
      "tree": "2e34678548e5323eef7392a94a7415e1754cbd1e",
      "parents": [
        "0a0a5af30b9831e4f049610b5a2d9d5108ff027a"
      ],
      "author": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Thu Jan 24 08:35:13 2008 +1100"
      },
      "committer": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Thu Jan 24 10:06:01 2008 +1100"
      },
      "message": "[POWERPC] Provide a way to protect 4k subpages when using 64k pages\n\nUsing 64k pages on 64-bit PowerPC systems makes life difficult for\nemulators that are trying to emulate an ISA, such as x86, which use a\nsmaller page size, since the emulator can no longer use the MMU and\nthe normal system calls for controlling page protections.  Of course,\nthe emulator can emulate the MMU by checking and possibly remapping\nthe address for each memory access in software, but that is pretty\nslow.\n\nThis provides a facility for such programs to control the access\npermissions on individual 4k sub-pages of 64k pages.  The idea is\nthat the emulator supplies an array of protection masks to apply to a\nspecified range of virtual addresses.  These masks are applied at the\nlevel where hardware PTEs are inserted into the hardware page table\nbased on the Linux PTEs, so the Linux PTEs are not affected.  Note\nthat this new mechanism does not allow any access that would otherwise\nbe prohibited; it can only prohibit accesses that would otherwise be\nallowed.  This new facility is only available on 64-bit PowerPC and\nonly when the kernel is configured for 64k pages.\n\nThe masks are supplied using a new subpage_prot system call, which\ntakes a starting virtual address and length, and a pointer to an array\nof protection masks in memory.  The array has a 32-bit word per 64k\npage to be protected; each 32-bit word consists of 16 2-bit fields,\nfor which 0 allows any access (that is otherwise allowed), 1 prevents\nwrite accesses, and 2 or 3 prevent any access.\n\nImplicit in this is that the regions of the address space that are\nprotected are switched to use 4k hardware pages rather than 64k\nhardware pages (on machines with hardware 64k page support).  In fact\nthe whole process is switched to use 4k hardware pages when the\nsubpage_prot system call is used, but this could be improved in future\nto switch only the affected segments.\n\nThe subpage protection bits are stored in a 3 level tree akin to the\npage table tree.  The top level of this tree is stored in a structure\nthat is appended to the top level of the page table tree, i.e., the\npgd array.  Since it will often only be 32-bit addresses (below 4GB)\nthat are protected, the pointers to the first four bottom level pages\nare also stored in this structure (each bottom level page contains the\nprotection bits for 1GB of address space), so the protection bits for\naddresses below 4GB can be accessed with one fewer loads than those\nfor higher addresses.\n\nSigned-off-by: Paul Mackerras \u003cpaulus@samba.org\u003e\n"
    },
    {
      "commit": "ee7a76da1ef5e3e5e0e54e84319e435ea25c267c",
      "tree": "df68b3ffb08df0a243085ddd59a9d4cfb2b01a6d",
      "parents": [
        "19a8d97d89442e2bda6245b8a3de2c1fec69a7ad"
      ],
      "author": {
        "name": "Stephen Rothwell",
        "email": "sfr@canb.auug.org.au",
        "time": "Tue Sep 18 17:22:59 2007 +1000"
      },
      "committer": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Wed Sep 19 15:25:34 2007 +1000"
      },
      "message": "[POWERPC] Size swapper_pg_dir correctly\n\nDavid Gibson pointed out that swapper_pg_dir actually need to be\nPGD_TABLE_SIZE bytes long not PAGE_SIZE.  This actually saves 64k in\nthe bss for a kernel ppc64_defconfig built with CONFIG_PPC_64K_PAGES.\n\nSigned-off-by: Stephen Rothwell \u003csfr@canb.auug.org.au\u003e\nSigned-off-by: Paul Mackerras \u003cpaulus@samba.org\u003e\n"
    },
    {
      "commit": "c0f7c6cb5dbb6d90e0334e62376dbc6ac3d1d315",
      "tree": "37c6d023d743a1bcf23f3caa28fae08310ef30a9",
      "parents": [
        "7a883eaf62f4b943ebec738ce3b0796c67ef5d32"
      ],
      "author": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Fri Aug 03 14:08:24 2007 +1000"
      },
      "committer": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Fri Aug 03 14:08:24 2007 +1000"
      },
      "message": "[POWERPC] Expand RPN field to 34 bits when using 64k pages\n\nThe real page number field in our PTEs when configured for 64kB pages\nis currently 32 bits, which turns out to be not quite enough for the\nresources that the eHCA driver wants to map.  This expands the RPN\nfield to include 2 adjacent, previously-unused bits.\n\nSigned-off-by: Paul Mackerras \u003cpaulus@samba.org\u003e\nAcked-by: Benjamin Herrenschmidt \u003cbenh@kernel.crashing.org\u003e"
    },
    {
      "commit": "16c2d476232523260c495eafbf9cdc1be984b7df",
      "tree": "fb6614b9752b51864e121317478088978823792c",
      "parents": [
        "d0f13e3c20b6fb73ccb467bdca97fa7cf5a574cd"
      ],
      "author": {
        "name": "Benjamin Herrenschmidt",
        "email": "benh@kernel.crashing.org",
        "time": "Tue May 08 16:27:28 2007 +1000"
      },
      "committer": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Wed May 09 16:35:00 2007 +1000"
      },
      "message": "[POWERPC] Add ability to 4K kernel to hash in 64K pages\n\nThis adds the ability for a kernel compiled with 4K page size\nto have special slices containing 64K pages and hash the right type\nof hash PTEs.\n\nSigned-off-by: Benjamin Herrenschmidt \u003cbenh@kernel.crashing.org\u003e\nSigned-off-by: Paul Mackerras \u003cpaulus@samba.org\u003e\n"
    },
    {
      "commit": "f88df14b1f15cdeffa060580a40c1ce3e13bb79e",
      "tree": "0619f32c2be79a85792537ad4410cc8d729f4f75",
      "parents": [
        "69d48b409cac747cc0707b05b769e38488a6ad35"
      ],
      "author": {
        "name": "David Gibson",
        "email": "david@gibson.dropbear.id.au",
        "time": "Mon Apr 30 16:30:56 2007 +1000"
      },
      "committer": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Wed May 02 20:04:30 2007 +1000"
      },
      "message": "[POWERPC] Remove arch/powerpc\u0027s dependence on asm-ppc/pg{alloc,table}.h\n\nCurrently, all 32-bit powerpc platforms use asm-ppc/pgtable.h and\nasm-ppc/pgalloc.h, even when otherwise compiled with ARCH\u003dpowerpc.\nThose asm-ppc files are a fairly nasty tangle of #ifdefs including a\nbunch of things which shouldn\u0027t be necessary any more in arch/powerpc.\n\nCleaning up that mess is going to take a while, but this patch is a\nfirst step.  It separates the asm-powerpc/pg{alloc,table}.h into 64\nbit and 32 bit versions in asm-powerpc, which the basic .h files in\nasm-powerpc select based on config.  We make a few tiny tweaks to the\ninnards of the files along the way, making the outermost ifdefs\n(double-inclusion protection and __KERNEL__) a little cleaner, and\n#including asm-generic/pgtable.h from the top-level\nasm-powerpc/pgtable.h (since both the old 32-bit and 64-bit versions\nended with such an #include).\n\nSigned-off-by: David Gibson \u003cdavid@gibson.dropbear.id.au\u003e\nSigned-off-by: Paul Mackerras \u003cpaulus@samba.org\u003e\n"
    },
    {
      "commit": "721151d004dcf01a71b12bb6b893f9160284cf6e",
      "tree": "16105646cae11ad6f785a5756d526b01922bcd7c",
      "parents": [
        "1a38147ed0737a9c01dbf5f2ca47fd2a0aa5cb55"
      ],
      "author": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Tue Apr 03 21:24:02 2007 +1000"
      },
      "committer": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Fri Apr 13 03:55:18 2007 +1000"
      },
      "message": "[POWERPC] Allow drivers to map individual 4k pages to userspace\n\nSome drivers have resources that they want to be able to map into\nuserspace that are 4k in size.  On a kernel configured with 64k pages\nwe currently end up mapping the 4k we want plus another 60k of\nphysical address space, which could contain anything.  This can\nintroduce security problems, for example in the case of an infiniband\nadaptor where the other 60k could contain registers that some other\nprogram is using for its communications.\n\nThis patch adds a new function, remap_4k_pfn, which drivers can use to\nmap a single 4k page to userspace regardless of whether the kernel is\nusing a 4k or a 64k page size.  Like remap_pfn_range, it would\ntypically be called in a driver\u0027s mmap function.  It only maps a\nsingle 4k page, which on a 64k page kernel appears replicated 16 times\nthroughout a 64k page.  On a 4k page kernel it reduces to a call to\nremap_pfn_range.\n\nThe way this works on a 64k kernel is that a new bit, _PAGE_4K_PFN,\ngets set on the linux PTE.  This alters the way that __hash_page_4K\ncomputes the real address to put in the HPTE.  The RPN field of the\nlinux PTE becomes the 4k RPN directly rather than being interpreted as\na 64k RPN.  Since the RPN field is 32 bits, this means that physical\naddresses being mapped with remap_4k_pfn have to be below 2^44,\ni.e. 0x100000000000.\n\nThe patch also factors out the code in arch/powerpc/mm/hash_utils_64.c\nthat deals with demoting a process to use 4k pages into one function\nthat gets called in the various different places where we need to do\nthat.  There were some discrepancies between exactly what was done in\nthe various places, such as a call to spu_flush_all_slbs in one case\nbut not in others.\n\nSigned-off-by: Paul Mackerras \u003cpaulus@samba.org\u003e\n"
    },
    {
      "commit": "bf72aeba2ffef599d1d386425c9e46b82be657cd",
      "tree": "ead8e5111dbcfa22e156999d1bb8a96e50f06fef",
      "parents": [
        "31925323b1b51bb65db729e029472a8b1f635b7d"
      ],
      "author": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Thu Jun 15 10:45:18 2006 +1000"
      },
      "committer": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Thu Jun 15 10:45:18 2006 +1000"
      },
      "message": "powerpc: Use 64k pages without needing cache-inhibited large pages\n\nSome POWER5+ machines can do 64k hardware pages for normal memory but\nnot for cache-inhibited pages.  This patch lets us use 64k hardware\npages for most user processes on such machines (assuming the kernel\nhas been configured with CONFIG_PPC_64K_PAGES\u003dy).  User processes\nstart out using 64k pages and get switched to 4k pages if they use any\nnon-cacheable mappings.\n\nWith this, we use 64k pages for the vmalloc region and 4k pages for\nthe imalloc region.  If anything creates a non-cacheable mapping in\nthe vmalloc region, the vmalloc region will get switched to 4k pages.\nI don\u0027t know of any driver other than the DRM that would do this,\nthough, and these machines don\u0027t have AGP.\n\nWhen a region gets switched from 64k pages to 4k pages, we do not have\nto clear out all the 64k HPTEs from the hash table immediately.  We\nuse the _PAGE_COMBO bit in the Linux PTE to indicate whether the page\nwas hashed in as a 64k page or a set of 4k pages.  If hash_page is\ntrying to insert a 4k page for a Linux PTE and it sees that it has\nalready been inserted as a 64k page, it first invalidates the 64k HPTE\nbefore inserting the 4k HPTE.  The hash invalidation routines also use\nthe _PAGE_COMBO bit, to determine whether to look for a 64k HPTE or a\nset of 4k HPTEs to remove.  With those two changes, we can tolerate a\nmix of 4k and 64k HPTEs in the hash table, and they will all get\nremoved when the address space is torn down.\n\nSigned-off-by: Paul Mackerras \u003cpaulus@samba.org\u003e\n"
    },
    {
      "commit": "88ced0314938814e1772b4d0d7ab20c52e4472b6",
      "tree": "3e06de882c0bf5706ee7a8994e06eb8c9ed3feca",
      "parents": [
        "e1333803c3a8fb167ba67ffc5540dbb53fa7deb3"
      ],
      "author": {
        "name": "Arnd Bergmann",
        "email": "arnd@arndb.de",
        "time": "Fri Dec 16 22:43:46 2005 +0100"
      },
      "committer": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Mon Jan 09 15:13:08 2006 +1100"
      },
      "message": "[PATCH] powerpc: sanitize header files for user space includes\n\ninclude/asm-ppc/ had #ifdef __KERNEL__ in all header files that\nare not meant for use by user space, include/asm-powerpc does\nnot have this yet.\n\nThis patch gets us a lot closer there. There are a few cases\nwhere I was not sure, so I left them out. I have verified\nthat no CONFIG_* symbols are used outside of __KERNEL__\nany more and that there are no obvious compile errors when\nincluding any of the headers in user space libraries.\n\nSigned-off-by: Arnd Bergmann \u003carnd@arndb.de\u003e\nSigned-off-by: Paul Mackerras \u003cpaulus@samba.org\u003e\n"
    },
    {
      "commit": "047ea7846565917c4a666635fa1fa4b5c587cd55",
      "tree": "409c8f6ddd1f145fb364a8d6f813febd0c94d06b",
      "parents": [
        "800fc3eeb0eed3bf98d621c0da24d68cabcf6526"
      ],
      "author": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Sat Nov 19 20:17:32 2005 +1100"
      },
      "committer": {
        "name": "Paul Mackerras",
        "email": "paulus@samba.org",
        "time": "Sat Nov 19 20:17:32 2005 +1100"
      },
      "message": "powerpc: Trivially merge several headers from asm-ppc64 to asm-powerpc\n\nFor these, I have just done the lame-o merge where the file ends up\nlooking like:\n\n\t#ifndef CONFIG_PPC64\n\t#include \u003casm-ppc/foo.h\u003e\n\t#else\n\t... contents from asm-ppc64/foo.h\n\t#endif\n\nso nothing has changed, really, except that we reduce include/asm-ppc64\na bit more.\n\nSigned-off-by: Paul Mackerras \u003cpaulus@samba.org\u003e\n"
    },
    {
      "commit": "7d24f0b8a53261709938ffabe3e00f88f6498df9",
      "tree": "95e192cdda64cbb7bb64451442c93a64d3932757",
      "parents": [
        "0b154bb7d0cce80e9c0bcf11d4f9e71b59409d26"
      ],
      "author": {
        "name": "David Gibson",
        "email": "david@gibson.dropbear.id.au",
        "time": "Mon Nov 07 00:57:52 2005 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Mon Nov 07 07:53:23 2005 -0800"
      },
      "message": "[PATCH] ppc64: Fix bug in SLB miss handler for hugepages\n\nThis patch, however, should be applied on top of the 64k-page-size patch to\nfix some problems with hugepage (some pre-existing, another introduced by\nthis patch).\n\nThe patch fixes a bug in the SLB miss handler for hugepages on ppc64\nintroduced by the dynamic hugepage patch (commit id\nc594adad5653491813959277fb87a2fef54c4e05) due to a misunderstanding of the\nsrd instruction\u0027s behaviour (mea culpa).  The problem arises when a 64-bit\nprocess maps some hugepages in the low 4GB of the address space (unusual).\nIn this case, as well as the 256M segment in question being marked for\nhugepages, other segments at 32G intervals will be incorrectly marked for\nhugepages.\n\nIn the process, this patch tweaks the semantics of the hugepage bitmaps to\nbe more sensible.  Previously, an address below 4G was marked for hugepages\nif the appropriate segment bit in the \"low areas\" bitmask was set *or* if\nthe low bit in the \"high areas\" bitmap was set (which would mark all\naddresses below 1TB for hugepage).  With this patch, any given address is\ngoverned by a single bitmap.  Addresses below 4GB are marked for hugepage\nif and only if their bit is set in the \"low areas\" bitmap (256M\ngranularity).  Addresses between 4GB and 1TB are marked for hugepage iff\nthe low bit in the \"high areas\" bitmap is set.  Higher addresses are marked\nfor hugepage iff their bit in the \"high areas\" bitmap is set (1TB\ngranularity).\n\nTo avoid conflicts, this patch must be applied on top of BenH\u0027s pending\npatch for 64k base page size [0].  As such, this patch also addresses a\nhugepage problem introduced by that patch.  That patch allows hugepages of\n1MB in size on hardware which supports it, however, that won\u0027t work when\nusing 4k pages (4 level pagetable), because in that case hugepage PTEs are\nstored at the PMD level, and each PMD entry maps 2MB.  This patch simply\ndisallows hugepages in that case (we can do something cleverer to re-enable\nthem some other day).\n\nBuilt, booted, and a handful of hugepage related tests passed on POWER5\nLPAR (both ARCH\u003dpowerpc and ARCH\u003dppc64).\n\n[0] http://gate.crashing.org/~benh/ppc64-64k-pages.diff\n\nSigned-off-by: David Gibson \u003cdavid@gibson.dropbear.id.au\u003e\nCc: Benjamin Herrenschmidt \u003cbenh@kernel.crashing.org\u003e\nCc: Paul Mackerras \u003cpaulus@samba.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "3c726f8dee6f55e96475574e9f645327e461884c",
      "tree": "f67c381e8f57959aa4a94bda4c68e24253cd8171",
      "parents": [
        "f912696ab330bf539231d1f8032320f2a08b850f"
      ],
      "author": {
        "name": "Benjamin Herrenschmidt",
        "email": "benh@kernel.crashing.org",
        "time": "Mon Nov 07 11:06:55 2005 +1100"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Sun Nov 06 16:56:47 2005 -0800"
      },
      "message": "[PATCH] ppc64: support 64k pages\n\nAdds a new CONFIG_PPC_64K_PAGES which, when enabled, changes the kernel\nbase page size to 64K.  The resulting kernel still boots on any\nhardware.  On current machines with 4K pages support only, the kernel\nwill maintain 16 \"subpages\" for each 64K page transparently.\n\nNote that while real 64K capable HW has been tested, the current patch\nwill not enable it yet as such hardware is not released yet, and I\u0027m\nstill verifying with the firmware architects the proper to get the\ninformation from the newer hypervisors.\n\nSigned-off-by: Benjamin Herrenschmidt \u003cbenh@kernel.crashing.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    }
  ]
}
