1. 24 7月, 2013 2 次提交
    • A
      powerpc/modules: Module CRC relocation fix causes perf issues · 0e0ed640
      Anton Blanchard 提交于
      Module CRCs are implemented as absolute symbols that get resolved by
      a linker script. We build an intermediate .o that contains an
      unresolved symbol for each CRC. genksysms parses this .o, calculates
      the CRCs and writes a linker script that "resolves" the symbols to
      the calculated CRC.
      
      Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
      that need relocating and relocates them at boot. Commit d4703aef
      (module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
      added a hook to reverse the bogus relocations. Part of this patch
      created a symbol at 0x0:
      
      # head -2 /proc/kallsyms
      0000000000000000 T reloc_start
      c000000000000000 T .__start
      
      This reloc_start symbol is causing lots of confusion to perf. It
      thinks reloc_start is a massive function that stretches from 0x0 to
      0xc000000000000000 and we get various cryptic errors out of perf,
      including:
      
      problem incrementing symbol count, skipping event
      
      This patch removes the  reloc_start linker script label and instead
      defines it as PHYSICAL_START. We also need to wrap it with
      CONFIG_PPC64 because the ppc32 kernel can set a non zero
      PHYSICAL_START at compile time and we wouldn't want to subtract
      it from the CRCs in that case.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: <stable@kernel.org>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      0e0ed640
    • M
      powerpc: Add second POWER8 PVR entry · 33959f88
      Michael Neuling 提交于
      POWER8 comes with two different PVRs.  This patch enables the additional
      PVR in the cputable.
      
      The existing entry (PVR=0x4b) is renamed to POWER8E and the new entry
      (PVR=0x4d) is given POWER8.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      33959f88
  2. 11 7月, 2013 1 次提交
  3. 02 7月, 2013 3 次提交
  4. 01 7月, 2013 8 次提交
  5. 30 6月, 2013 1 次提交
    • P
      KVM: PPC: Book3S PR: Allow guest to use 1TB segments · 0f296829
      Paul Mackerras 提交于
      With this, the guest can use 1TB segments as well as 256MB segments.
      Since we now have the situation where a single emulated guest segment
      could correspond to multiple shadow segments (as the shadow segments
      are still 256MB segments), this adds a new kvmppc_mmu_flush_segment()
      to scan for all shadow segments that need to be removed.
      
      This restructures the guest HPT (hashed page table) lookup code to
      use the correct hashing and matching functions for HPTEs within a
      1TB segment.  We use the standard hpt_hash() function instead of
      open-coding the hash calculation, and we use HPTE_V_COMPARE() with
      an AVPN value that has the B (segment size) field included.  The
      calculation of avpn is done a little earlier since it doesn't change
      in the loop starting at the do_second label.
      
      The computation in kvmppc_mmu_book3s_64_esid_to_vsid() changes so that
      it returns a 256MB VSID even if the guest SLB entry is a 1TB entry.
      This is because the users of this function are creating 256MB SLB
      entries.  We set a new VSID_1T flag so that entries created from 1T
      segments don't collide with entries from 256MB segments.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      0f296829
  6. 29 6月, 2013 1 次提交
  7. 26 6月, 2013 1 次提交
  8. 25 6月, 2013 2 次提交
  9. 21 6月, 2013 10 次提交
  10. 20 6月, 2013 11 次提交