1. 13 5月, 2016 7 次提交
    • J
      MIPS: Add defs & probing of [X]ContextConfig · f18bdfa1
      James Hogan 提交于
      The CP0_[X]ContextConfig registers are present if CP0_Config3.CTXTC or
      CP0_Config3.SM are set, and provide more control over which bits of
      CP0_[X]Context are set to the faulting virtual address on a TLB
      exception.
      
      KVM/VZ will need to be able to save and restore these registers in the
      guest context, so add the relevant definitions and probing of the
      ContextConfig feature in the root context first.
      
      [ralf@linux-mips.org: resolve merge conflict.]
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13225/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f18bdfa1
    • J
      MIPS: Add defs & probing of BadInstr[P] registers · e06a1548
      James Hogan 提交于
      The optional CP0_BadInstr and CP0_BadInstrP registers are written with
      the encoding of the instruction that caused a synchronous exception to
      occur, and the prior branch instruction if in a delay slot.
      
      These will be useful for instruction emulation in KVM, and especially
      for VZ support where reading guest virtual memory is a bit more awkward.
      
      Add CPU option numbers and cpu_has_* definitions to indicate the
      presence of each registers, and add code to probe for them using bits in
      the CP0_Config3 register.
      
      [ralf@linux-mips.org: resolve merge conflict.]
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13224/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e06a1548
    • J
      MIPS: Add defs & probing of extended CP0_EBase · 37fb60f8
      James Hogan 提交于
      The CP0_EBase register may optionally have a write gate (WG) bit to
      allow the upper bits to be written, i.e. bits 31:30 on MIPS32 since r3
      (to allow for an exception base outside of KSeg0/KSeg1 when segmentation
      control is in use) and bits 63:30 on MIPS64 (which also implies the
      extension of CP0_EBase to 64 bits long).
      
      The presence of this feature will need to be known about for VZ support
      in order to correctly save and restore all the bits of the guest
      CP0_EBase register, so add CPU feature definition and probing for this
      feature.
      
      Probing the WG bit on MIPS64 can be a bit fiddly, since 64-bit COP0
      register access instructions were UNDEFINED for 32-bit registers prior
      to MIPS r6, and it'd be nice to be able to probe without clobbering the
      existing state, so there are 3 potential paths:
      
      - If we do a 32-bit read of CP0_EBase and the WG bit is already set, the
        register must be 64-bit.
      
      - On MIPS r6 we can do a 64-bit read-modify-write to set CP0_EBase.WG,
        since the upper bits will read 0 and be ignored on write if the
        register is 32-bit.
      
      - On pre-r6 cores, we do a 32-bit read-modify-write of CP0_EBase. This
        avoids the potentially UNDEFINED behaviour, but will clobber the upper
        32-bits of CP0_EBase if it isn't a simple sign extension (which also
        requires us to ensure BEV=1 or modifying the exception base would be
        UNDEFINED too). It is hopefully unlikely a bootloader would set up
        CP0_EBase to a 64-bit segment and leave WG=0.
      
      [ralf@linux-mips.org: Resolved merge conflict.]
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Tested-by: NMatt Redfearn <matt.redfearn@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13223/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      37fb60f8
    • J
      MIPS: Separate XPA CPU feature into LPA and MVH · 12822570
      James Hogan 提交于
      XPA (eXtended Physical Addressing) should be detected as a combination
      of two architectural features:
      - Large Physical Address (as per Config3.LPA). With XPA this will be set
        on MIPS32r5 cores, but it may also be set for MIPS64r2 cores too.
      - MTHC0/MFHC0 instructions (as per Config5.MVH). With XPA this will be
        set, but it may also be set in VZ guest context even when Config3.LPA
        in the guest context has been cleared by the hypervisor.
      
      As such, XPA is only usable if both bits are set. Update CPU features to
      separate these two features, with cpu_has_xpa requiring both to be set.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Maciej W. Rozycki <macro@imgtec.com>
      Cc: Joshua Kinard <kumba@gentoo.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13112/Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      12822570
    • H
      MIPS: Loongson-3: Fast TLB refill handler · 380cd582
      Huacai Chen 提交于
      Loongson-3A R2 has pwbase/pwfield/pwsize/pwctl registers in CP0 (this
      is very similar to HTW) and lwdir/lwpte/lddir/ldpte instructions which
      can be used for fast TLB refill.
      
      [ralf@linux-mips.org: Resolve conflict.]
      Signed-off-by: NHuacai Chen <chenhc@lemote.com>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Cc: Steven J . Hill <sjhill@realitydiluted.com>
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/12754/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      380cd582
    • Z
      MIPS: Detect DSP v3 support · b5a6455c
      Zubair Lutfullah Kakakhel 提交于
      DSPv3 is supported on all MIPSr6 systems which indicate support for DSPv2.
      
      This doesn't require any changes to the kernel's handling of DSP
      resources. The patch is to detect support and indicate it in /proc/cpuinfo
      
      DSP v3 introduces a new instruction BPOSGE32C
      Signed-off-by: NZubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
      Reviewed-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/12918/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b5a6455c
    • P
      MIPS: Detect MIPSr6 Virtual Processor support · f270d881
      Paul Burton 提交于
      MIPSr6 introduces support for "Virtual Processors", which are
      conceptually similar to VPEs from the now-deprecated MT ASE. Detect
      whether the system supports VPs using the VP bit in Config5, adding
      cpu_has_vp for use by later patches.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Maciej W. Rozycki <macro@imgtec.com>
      Cc: Joshua Kinard <kumba@gentoo.org>
      Cc: Steven J. Hill <sjhill@realitydiluted.com>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/12327/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f270d881
  2. 20 1月, 2016 1 次提交
  3. 11 11月, 2015 1 次提交
    • P
      MIPS: Allow RIXI for 32-bit kernels on MIPS64 · 033549c6
      Paul Burton 提交于
      Commit a68d09a1 ("MIPS: Don't use RI/XI with 32-bit kernels on
      64-bit CPUs") prevented use of RIXI on MIPS64 systems, stating that the
      "TLB handlers cannot handle this case". What they actually couldn't
      handle was cases where there were less fill bits in the Entry{Lo,Hi}
      registers than bits used by software in PTEs. The handlers can now deal
      with this case, so enable RIXI for MIPS32 kernels on MIPS64 systems.
      
      Note that beyond the obvious benefits provided by having RIXI on such
      systems, this is required for systems implementing MIPSr6 where RIXI
      cannot be disabled.
      
      This reverts commit a68d09a1 ("MIPS: Don't use RI/XI with 32-bit
      kernels on 64-bit CPUs").
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Joshua Kinard <kumba@gentoo.org>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Patchwork: https://patchwork.linux-mips.org/patch/11219/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      033549c6
  4. 23 9月, 2015 1 次提交
  5. 03 9月, 2015 1 次提交
  6. 22 6月, 2015 1 次提交
    • J
      MIPS: R12000: Enable branch prediction global history · 8d5ded16
      Joshua Kinard 提交于
      The R12000 added a new feature to enhance branch prediction called
      "global history".  Per the Vr10000 Series User Manual (U10278EJ4V0UM),
      Coprocessor 0, Diagnostic Register (22):
      
      """
      If bit 26 is set, branch prediction uses all eight bits of the global
      history register.  If bit 26 is not set, then bits 25:23 specify a count
      of the number of bits of global history to be used. Thus if bits 26:23
      are all zero, global history is disabled.
      
      The global history contains a record of the taken/not-taken status of
      recently executed branches, and when used is XOR'ed with the PC of a
      branch being predicted to produce a hashed value for indexing the BPT.
      Some programs with small "working set of conditional branches" benefit
      significantly from the use of such hashing, some see slight performance
      degradation.
      """
      
      This patch enables global history on R12000 CPUs and up by setting bit
      26 in the branch prediction diagnostic register (CP0 $22) to '1'.  Bits
      25:23 are left alone so that all eight bits of the global history
      register are available for branch prediction.
      Signed-off-by: NJoshua Kinard <kumba@gentoo.org>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      8d5ded16
  7. 10 4月, 2015 1 次提交
  8. 08 4月, 2015 2 次提交
  9. 31 3月, 2015 1 次提交
  10. 20 3月, 2015 1 次提交
  11. 17 2月, 2015 4 次提交
  12. 24 11月, 2014 1 次提交
  13. 22 9月, 2014 1 次提交
  14. 02 8月, 2014 3 次提交
  15. 31 5月, 2014 1 次提交
  16. 21 5月, 2014 1 次提交
  17. 27 3月, 2014 2 次提交
  18. 23 1月, 2014 2 次提交
  19. 24 9月, 2013 1 次提交
  20. 18 9月, 2013 1 次提交
  21. 05 8月, 2013 1 次提交
    • R
      MIPS: oprofile: Fix BUG due to smp_processor_id() in preemptible code. · cf5b2d23
      Ralf Baechle 提交于
      current_cpu_type() is not preemption-safe.
      If CONFIG_PREEMPT is enabled then mipsxx_reg_setup() can be called from preemptible state.
      Added get_cpu()/put_cpu() pair to make it preemption-safe.
      
      This was found while testing oprofile with CONFIG_DEBUG_PREEMPT enable.
      
      /usr/zntestsuite # opcontrol --init
      /usr/zntestsuite # opcontrol --setup --event=L2_CACHE_ACCESSES:500 --event=L2_CACHE_MISSES:500 --no-vmlinux
      /usr/zntestsuite # opcontrol --start
      Using 2.6+ OProfile kernel interface.
      BUG: using smp_processor_id() in preemptible [00000000] code: oprofiled/1362
      caller is mipsxx_reg_setup+0x11c/0x164
      CPU: 0 PID: 1362 Comm: oprofiled Not tainted 3.10.4 #18
      Stack : 00000006 70757465 00000000 00000000 00000000 00000000 80b173f6 00000037
                80b10000 00000000 80b21614 88f5a220 00000000 00000000 00000000 00000000
                00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
                00000000 00000000 00000000 89c49c00 89c49c2c 80721254 807b7927 8012c1d0
                80b10000 80721254 00000000 00000552 88f5a220 80b1335c 807b78e6 89c49ba8
                ...
      Call Trace:
      [<801099a4>] show_stack+0x64/0x7c
      [<80665520>] dump_stack+0x20/0x2c
      [<803a2250>] debug_smp_processor_id+0xe0/0xf0
      [<8052df24>] mipsxx_reg_setup+0x11c/0x164
      [<8052cd70>] op_mips_setup+0x24/0x4c
      [<80529cfc>] oprofile_setup+0x5c/0x12c
      [<8052b9f8>] event_buffer_open+0x78/0xf8
      [<801c3150>] do_dentry_open.isra.15+0x2b8/0x3b0
      [<801c3270>] finish_open+0x28/0x4c
      [<801d49b8>] do_last.isra.41+0x2cc/0xd00
      [<801d54a0>] path_openat+0xb4/0x4c4
      [<801d5c44>] do_filp_open+0x3c/0xac
      [<801c4744>] do_sys_open+0x110/0x1f4
      [<8010f47c>] stack_done+0x20/0x44
      
      Bug reported and original patch by Jerin Jacob <jerinjacobk@gmail.com>.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NJerin Jacob <jerinjacobk@gmail.com>
      cf5b2d23
  22. 01 7月, 2013 3 次提交
  23. 08 5月, 2013 1 次提交
    • H
      MIPS: Build uasm-generated code only once to avoid CPU Hotplug problem · 8759934e
      Huacai Chen 提交于
      This and the next patch resolve memory corruption problems while CPU
      hotplug. Without these patches, memory corruption can triggered easily
      as below:
      
      On a quad-core MIPS platform, use "spawn" of UnixBench-5.1.3 (http://
      code.google.com/p/byte-unixbench/) and a CPU hotplug script like this
      (hotplug.sh):
      while true; do
      echo 0 >/sys/devices/system/cpu/cpu1/online
      echo 0 >/sys/devices/system/cpu/cpu2/online
      echo 0 >/sys/devices/system/cpu/cpu3/online
      sleep 1
      echo 1 >/sys/devices/system/cpu/cpu1/online
      echo 1 >/sys/devices/system/cpu/cpu2/online
      echo 1 >/sys/devices/system/cpu/cpu3/online
      sleep 1
      done
      
      Run "hotplug.sh" and then run "spawn 10000", spawn will get segfault
      after a few minutes.
      
      This patch:
      Currently, clear_page()/copy_page() are generated by Micro-assembler
      dynamically. But they are unavailable until uasm_resolve_relocs() has
      finished because jump labels are illegal before that. Since these
      functions are shared by every CPU, we only call build_clear_page()/
      build_copy_page() only once at boot time. Without this patch, programs
      will get random memory corruption (segmentation fault, bus error, etc.)
      while CPU Hotplug (e.g. one CPU is using clear_page() while another is
      generating it in cpu_cache_init()).
      
      For similar reasons we modify build_tlb_refill_handler()'s invocation.
      
      V2:
      1, Rework the code to make CPU#0 can be online/offline.
      2, Introduce cpu_has_local_ebase feature since some types of MIPS CPU
         need a per-CPU tlb_refill_handler().
      Signed-off-by: NHuacai Chen <chenhc@lemote.com>
      Signed-off-by: NHongbing Hu <huhb@lemote.com>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      Patchwork: http://patchwork.linux-mips.org/patch/4994/Acked-by: NJohn Crispin <blogic@openwrt.org>
      8759934e
  24. 19 2月, 2013 1 次提交