1. 02 5月, 2008 2 次提交
    • P
      [POWERPC] Bolt in SLB entry for kernel stack on secondary cpus · 3b575064
      Paul Mackerras 提交于
      This fixes a regression reported by Kamalesh Bulabel where a POWER4
      machine would crash because of an SLB miss at a point where the SLB
      miss exception was unrecoverable.  This regression is tracked at:
      
      http://bugzilla.kernel.org/show_bug.cgi?id=10082
      
      SLB misses at such points shouldn't happen because the kernel stack is
      the only memory accessed other than things in the first segment of the
      linear mapping (which is mapped at all times by entry 0 of the SLB).
      The context switch code ensures that SLB entry 2 covers the kernel
      stack, if it is not already covered by entry 0.  None of entries 0
      to 2 are ever replaced by the SLB miss handler.
      
      Where this went wrong is that the context switch code assumes it
      doesn't have to write to SLB entry 2 if the new kernel stack is in the
      same segment as the old kernel stack, since entry 2 should already be
      correct.  However, when we start up a secondary cpu, it calls
      slb_initialize, which doesn't set up entry 2.  This is correct for
      the boot cpu, where we will be using a stack in the kernel BSS at this
      point (i.e. init_thread_union), but not necessarily for secondary
      cpus, whose initial stack can be allocated anywhere.  This doesn't
      cause any immediate problem since the SLB miss handler will just
      create an SLB entry somewhere else to cover the initial stack.
      
      In fact it's possible for the cpu to go quite a long time without SLB
      entry 2 being valid.  Eventually, though, the entry created by the SLB
      miss handler will get overwritten by some other entry, and if the next
      access to the stack is at an unrecoverable point, we get the crash.
      
      This fixes the problem by making slb_initialize create a suitable
      entry for the kernel stack, if we are on a secondary cpu and the stack
      isn't covered by SLB entry 0.  This requires initializing the
      get_paca()->kstack field earlier, so I do that in smp_create_idle
      where the current field is initialized.  This also abstracts a bit of
      the computation that mk_esid_data in slb.c does so that it can be used
      in slb_initialize.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3b575064
    • G
      [POWERPC] Fix slb.c compile warnings · bbea3460
      Geoff Levand 提交于
      Arrange for a syntax check to always be done on the powerpc/mm/slb.c
      DBG() macro by defining it to pr_debug() for non-debug builds.
      
      Also, fix these related compile warnings:
      
        slb.c:273: warning: format '%04x' expects type 'unsigned int', but argument 2 has type 'long unsigned int
        slb.c:274: warning: format '%04x' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
      Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      bbea3460
  2. 29 4月, 2008 1 次提交
  3. 28 4月, 2008 1 次提交
  4. 24 4月, 2008 4 次提交
    • K
      [POWERPC] Clean up access to thread_info in assembly · f608600e
      Kumar Gala 提交于
      Use (31-THREAD_SHIFT) to get to thread_info from stack pointer.  This makes
      the code a bit easier to read and more robust if we ever change THREAD_SHIFT.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f608600e
    • K
      [POWERPC] Port fixmap from x86 and use for kmap_atomic · 2c419bde
      Kumar Gala 提交于
      The fixmap code from x86 allows us to have compile time virtual addresses
      that we change the physical addresses of at run time.
      
      This is useful for applications like kmap_atomic, PCI config that is done
      via direct memory map, kexec/kdump.
      
      We got ride of CONFIG_HIGHMEM_START as we can now determine a more optimal
      location for PKMAP_BASE based on where the fixmap addresses start and
      working back from there.
      
      Additionally, the kmap code in asm-powerpc/highmem.h always had debug
      enabled.  Moved to using CONFIG_DEBUG_HIGHMEM to determine if we should
      have the extra debug checking.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      2c419bde
    • K
      [POWERPC] 85xx: Add support for relocatable kernel (and booting at non-zero) · 37dd2bad
      Kumar Gala 提交于
      Added support to allow an 85xx kernel to be run from a non-zero physical
      address (useful for cooperative asymmetric multiprocessing situations and
      kdump).  The support can be configured at compile time by setting
      CONFIG_PAGE_OFFSET, CONFIG_KERNEL_START, and CONFIG_PHYSICAL_START as
      desired.
      
      Alternatively, the kernel build can set CONFIG_RELOCATABLE.  Setting this
      config option causes the kernel to determine at runtime the physical
      addresses of CONFIG_PAGE_OFFSET and CONFIG_KERNEL_START.  If
      CONFIG_RELOCATABLE is set, then CONFIG_PHYSICAL_START has no meaning.
      However, CONFIG_PHYSICAL_START will always be used to set the LOAD program
      header physical address field in the resulting ELF image.
      
      Currently we are limited to running at a physical address that is a
      multiple of 256M.  This is due to how we map TLBs to cover
      lowmem.  This should be fixed to allow 64M or maybe even 16M alignment
      in the future.  It is considered an error to try and run a kernel at a
      non-aligned physical address.
      
      All the magic for this support is accomplished by proper initialization
      of the kernel memory subsystem and use of ARCH_PFN_OFFSET.
      
      The use of ARCH_PFN_OFFSET only affects normal memory and not IO mappings.
      ioremap uses map_page and isn't affected by ARCH_PFN_OFFSET.
      
      /dev/mem continues to allow access to any physical address in the system
      regardless of how CONFIG_PHYSICAL_START is set.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      37dd2bad
    • M
      [POWERPC] Add include of linux/of.h to numa.c · 6df1646e
      Michael Ellerman 提交于
      numa.c requires routines declared in linux/of.h, so should include it.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      6df1646e
  5. 18 4月, 2008 1 次提交
  6. 17 4月, 2008 5 次提交
  7. 07 4月, 2008 1 次提交
  8. 03 4月, 2008 1 次提交
  9. 01 4月, 2008 4 次提交
  10. 24 3月, 2008 1 次提交
    • P
      [POWERPC] Don't use 64k pages for ioremap on pSeries · cfe666b1
      Paul Mackerras 提交于
      On pSeries, the hypervisor doesn't let us map in the eHEA ethernet
      adapter using 64k pages, and thus the ehea driver will fail if 64k
      pages are configured.  This works around the problem by always
      using 4k pages for ioremap on pSeries (but not on other platforms).
      A better fix would be to check whether the partition could ever
      have an eHEA adapter, and only force 4k pages if it could, but this
      will do for 2.6.25.
      
      This is based on an earlier patch by Tony Breeds.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cfe666b1
  11. 20 3月, 2008 1 次提交
  12. 13 3月, 2008 1 次提交
    • M
      [POWERPC] Fix large hash table allocation on Cell blades · 31bf1119
      Michael Ellerman 提交于
      My recent hack to allocate the hash table under 1GB on cell was poorly
      tested, *cough*. It turns out on blades with large amounts of memory we
      fail to allocate the hash table at all. This is because RTAS has been
      instantiated just below 768MB, and 0-x MB are used by the kernel,
      leaving no areas that are both large enough and also naturally-aligned.
      
      For the cell IOMMU hack the page tables must be under 2GB, so use that
      as the limit instead. This has been tested on real hardware and boots
      happily.
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      31bf1119
  13. 26 2月, 2008 1 次提交
  14. 14 2月, 2008 1 次提交
  15. 09 2月, 2008 1 次提交
    • M
      CONFIG_HIGHPTE vs. sub-page page tables. · 2f569afd
      Martin Schwidefsky 提交于
      Background: I've implemented 1K/2K page tables for s390.  These sub-page
      page tables are required to properly support the s390 virtualization
      instruction with KVM.  The SIE instruction requires that the page tables
      have 256 page table entries (pte) followed by 256 page status table entries
      (pgste).  The pgstes are only required if the process is using the SIE
      instruction.  The pgstes are updated by the hardware and by the hypervisor
      for a number of reasons, one of them is dirty and reference bit tracking.
      To avoid wasting memory the standard pte table allocation should return
      1K/2K (31/64 bit) and 2K/4K if the process is using SIE.
      
      Problem: Page size on s390 is 4K, page table size is 1K or 2K.  That means
      the s390 version for pte_alloc_one cannot return a pointer to a struct
      page.  Trouble is that with the CONFIG_HIGHPTE feature on x86 pte_alloc_one
      cannot return a pointer to a pte either, since that would require more than
      32 bit for the return value of pte_alloc_one (and the pte * would not be
      accessible since its not kmapped).
      
      Solution: The only solution I found to this dilemma is a new typedef: a
      pgtable_t.  For s390 pgtable_t will be a (pte *) - to be introduced with a
      later patch.  For everybody else it will be a (struct page *).  The
      additional problem with the initialization of the ptl lock and the
      NR_PAGETABLE accounting is solved with a constructor pgtable_page_ctor and
      a destructor pgtable_page_dtor.  The page table allocation and free
      functions need to call these two whenever a page table page is allocated or
      freed.  pmd_populate will get a pgtable_t instead of a struct page pointer.
       To get the pgtable_t back from a pmd entry that has been installed with
      pmd_populate a new function pmd_pgtable is added.  It replaces the pmd_page
      call in free_pte_range and apply_to_pte_range.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f569afd
  16. 08 2月, 2008 3 次提交
  17. 07 2月, 2008 1 次提交
    • B
      [POWERPC] Fake NUMA emulation for PowerPC · 1daa6d08
      Balbir Singh 提交于
      Here's a dumb simple implementation of fake NUMA nodes for PowerPC.
      Fake NUMA nodes can be specified using the following command line
      option
      
      numa=fake=<node range>
      
      node range is of the format <range1>,<range2>,...<rangeN>
      
      Each of the rangeX parameters is passed using memparse().  I find the
      patch useful for fake NUMA emulation on my simple PowerPC machine.
      I've tested it on a numa box with the following arguments
      
      numa=fake=512M
      numa=fake=512M,768M
      numa=fake=256M,512M mem=512M
      numa=fake=1G mem=768M
      numa=fake=
      without any numa= argument
      
      The other side-effect introduced by this patch is that; in the case
      where we don't have NUMA information, we now set a node online after
      adding each LMB.  This node could very well be node 0, but in the case
      that we enable fake NUMA nodes, when we cross node boundaries, we need
      to set the new node online.
      Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1daa6d08
  18. 06 2月, 2008 2 次提交
  19. 31 1月, 2008 1 次提交
  20. 26 1月, 2008 1 次提交
    • P
      Revert "[POWERPC] Fake NUMA emulation for PowerPC" · 55852bed
      Paul Mackerras 提交于
      This reverts commit 5c3f5892,
      basically because it changes behaviour even when no fake NUMA
      information is specified on the kernel command line.
      
      Firstly, it changes the nid, thus destroying the real NUMA
      information.  Secondly, it also changes behaviour in that if a node
      ends up with no memory in it because of the memory limit, we used to
      set it online and now we don't.
      
      Also, in the non-NUMA case with no fake NUMA information, we do
      node_set_online once for each LMB now, whereas previously we only did
      it once.  I don't know if that is actually a problem, but it does seem
      unnecessary.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      55852bed
  21. 25 1月, 2008 1 次提交
  22. 24 1月, 2008 3 次提交
    • D
      [POWERPC] 85xx: Respect KERNELBASE, PAGE_OFFSET, and PHYSICAL_START on e500 · e8b63761
      Dale Farnsworth 提交于
      The e500 MMU init code previously assumed KERNELBASE always equaled
      PAGE_OFFSET and PHYSICAL_START was 0.  This is useful for kdump
      support as well as asymetric multicore.
      
      For the initial kdump support the secondary kernel will run at 32M
      but need access to all of memory so we bump the initial TLB up to
      64M.  This also matches with the forth coming ePAPR spec.
      Signed-off-by: NDale Farnsworth <dale@farnsworth.org>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      e8b63761
    • K
      [POWERPC] Fix handling of memreserve if the range lands in highmem · f98eeb4e
      Kumar Gala 提交于
      There were several issues if a memreserve range existed and happened
      to be in highmem:
      
      * The bootmem allocator is only aware of lowmem so calling
        reserve_bootmem with a highmem address would cause a BUG_ON
      * All highmem pages were provided to the buddy allocator
      
      Added a lmb_is_reserved() api that we now use to determine if a highem
      page should continue to be PageReserved or provided to the buddy
      allocator.
      
      Also, we incorrectly reported the amount of pages reserved since all
      highmem pages are initally marked reserved and we clear the
      PageReserved flag as we "free" up the highmem pages.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      f98eeb4e
    • P
      [POWERPC] Provide a way to protect 4k subpages when using 64k pages · fa28237c
      Paul Mackerras 提交于
      Using 64k pages on 64-bit PowerPC systems makes life difficult for
      emulators that are trying to emulate an ISA, such as x86, which use a
      smaller page size, since the emulator can no longer use the MMU and
      the normal system calls for controlling page protections.  Of course,
      the emulator can emulate the MMU by checking and possibly remapping
      the address for each memory access in software, but that is pretty
      slow.
      
      This provides a facility for such programs to control the access
      permissions on individual 4k sub-pages of 64k pages.  The idea is
      that the emulator supplies an array of protection masks to apply to a
      specified range of virtual addresses.  These masks are applied at the
      level where hardware PTEs are inserted into the hardware page table
      based on the Linux PTEs, so the Linux PTEs are not affected.  Note
      that this new mechanism does not allow any access that would otherwise
      be prohibited; it can only prohibit accesses that would otherwise be
      allowed.  This new facility is only available on 64-bit PowerPC and
      only when the kernel is configured for 64k pages.
      
      The masks are supplied using a new subpage_prot system call, which
      takes a starting virtual address and length, and a pointer to an array
      of protection masks in memory.  The array has a 32-bit word per 64k
      page to be protected; each 32-bit word consists of 16 2-bit fields,
      for which 0 allows any access (that is otherwise allowed), 1 prevents
      write accesses, and 2 or 3 prevent any access.
      
      Implicit in this is that the regions of the address space that are
      protected are switched to use 4k hardware pages rather than 64k
      hardware pages (on machines with hardware 64k page support).  In fact
      the whole process is switched to use 4k hardware pages when the
      subpage_prot system call is used, but this could be improved in future
      to switch only the affected segments.
      
      The subpage protection bits are stored in a 3 level tree akin to the
      page table tree.  The top level of this tree is stored in a structure
      that is appended to the top level of the page table tree, i.e., the
      pgd array.  Since it will often only be 32-bit addresses (below 4GB)
      that are protected, the pointers to the first four bottom level pages
      are also stored in this structure (each bottom level page contains the
      protection bits for 1GB of address space), so the protection bits for
      addresses below 4GB can be accessed with one fewer loads than those
      for higher addresses.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      fa28237c
  23. 17 1月, 2008 1 次提交
  24. 15 1月, 2008 1 次提交
    • P
      [POWERPC] Fix boot failure on POWER6 · dfbe0d3b
      Paul Mackerras 提交于
      Commit 473980a9 added a call to clear
      the SLB shadow buffer before registering it.  Unfortunately this means
      that we clear out the entries that slb_initialize has previously set in
      there.  On POWER6, the hypervisor uses the SLB shadow buffer when doing
      partition switches, and that means that after the next partition switch,
      each non-boot CPU has no SLB entries to map the kernel text and data,
      which causes it to crash.
      
      This fixes it by reverting most of 473980a9 and instead clearing the
      3rd entry explicitly in slb_initialize.  This fixes the problem that
      473980a9 was trying to solve, but without breaking POWER6.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      dfbe0d3b