1. 14 2月, 2017 1 次提交
  2. 10 2月, 2017 8 次提交
  3. 09 2月, 2017 1 次提交
  4. 07 2月, 2017 3 次提交
  5. 06 2月, 2017 6 次提交
  6. 02 2月, 2017 4 次提交
  7. 31 1月, 2017 6 次提交
  8. 30 1月, 2017 2 次提交
    • A
      powerpc/powernv: Initialise nest mmu · 1d0761d2
      Alistair Popple 提交于
      POWER9 contains an off core mmu called the nest mmu (NMMU). This is
      used by other hardware units on the chip to translate virtual
      addresses into real addresses. The unit attempting an address
      translation provides the majority of the context required for the
      translation request except for the base address of the partition table
      (ie. the PTCR) which needs to be programmed into the NMMU.
      
      This patch adds a call to OPAL to set the PTCR for the nest mmu in
      opal_init().
      Signed-off-by: NAlistair Popple <alistair@popple.id.au>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      1d0761d2
    • A
      powerpc/mm/hash: Properly mask the ESID bits when building proto VSID · 79270e0a
      Aneesh Kumar K.V 提交于
      The proto VSID is built using both the MMU context id and effective
      segment ID (ESID). We should not have overlapping bits between those.
      That could result in us having a VSID collision. With the current code
      we missed masking the top bits of the ESID. This implies for kernel
      address we ended up using the top 4 bits of the ESID as part of the
      proto VSID, which is wrong.
      
      The current code use the top 4 context values (0x7fffc - 0x7ffff) for
      the kernel. With those context IDs used for the kernel, we don't run
      into VSID collisions because we get the same proto VSID irrespective of
      whether we mask the ESID bits or not. eg:
      
        ea         = 0xf000000000000000
        context    = 0x7ffff
      
        w/out masking:
        proto_vsid = (0x7ffff << 6 | 0xf000000000000000 >> 40)
      	     = (0x1ffffc0 | 0xf00000)
      	     =  0x1ffffc0
      
        with masking:
        proto_vsid = (0x7ffff << 6 | ((0xf000000000000000 >> 40) & 0x3f))
      	     = (0x1ffffc0 | (0xf00000 & 0x3f))
      	     =  0x1ffffc0 | 0)
      	     =  0x1ffffc0
      
      So although there is no bug, the code is still overly subtle, so fix it
      to save ourselves pain in future.
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      79270e0a
  9. 25 1月, 2017 3 次提交
  10. 23 1月, 2017 2 次提交
  11. 20 1月, 2017 1 次提交
    • A
      powerpc: Ignore reserved field in DCSR and PVR reads and writes · 178f3582
      Anton Blanchard 提交于
      IBM bit 31 (for the rest of us - bit 0) is a reserved field in the
      instruction definition of mtspr and mfspr. Hardware is encouraged to
      (and does) ignore it.
      
      As a result, if userspace executes an mtspr DSCR with the reserved bit
      set, we get a DSCR facility unavailable exception. The kernel fails to
      match against the expected value/mask, and we silently return to
      userspace to try and re-execute the same mtspr DSCR instruction. We
      loop forever until the process is killed.
      
      We should do something here, and it seems mirroring what hardware does
      is the better option vs killing the process. While here, relax the
      matching of mfspr PVR too.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      178f3582
  12. 18 1月, 2017 2 次提交
  13. 17 1月, 2017 1 次提交