kernel.git/arch/mips/include/asm/cpu-features.h, branch linux-5.8.y

MIPS: only register FTLBPar exception handler for supported models

2020-08-19T06:26:51Z

[ Upstream commit efd1b4ad3d5178a74387bc5ff69a2d4585f586c6 ] Previously ExcCode 16 is unconditionally treated as the FTLB parity exception (FTLBPar), but in fact its semantic is implementation- dependent. Looking at various manuals it seems the FTLBPar exception is only present on some recent MIPS Technologies cores, so only register the handler on these. Fixes: 75b5b5e0a262790f ("MIPS: Add support for FTLBs") Reviewed-by: Huacai Chen Signed-off-by: WANG Xuerui Cc: Paul Burton Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

KVM: MIPS: Introduce and use cpu_guest_has_ldpte

2020-06-04T17:49:00Z

Loongson-3 has lddir/ldpte instructions and their related CP0 registers are the same as HTW. So we introduce a cpu_guest_has_ldpte flag and use it to indicate whether we need to save/restore HTW related CP0 registers (PWBase, PWSize, PWField and PWCtl). Acked-by: Thomas Bogendoerfer Reviewed-by: Aleksandar Markovic Signed-off-by: Huacai Chen Co-developed-by: Jiaxun Yang Message-Id: <1590220602-3547-7-git-send-email-chenhc@lemote.com> Signed-off-by: Paolo Bonzini

mips: Add CP0 Write Merge config support

2020-05-22T07:11:45Z

CP0 config register may indicate whether write-through merging is allowed. Currently there are two types of the merging available: SysAD Valid and Full modes. Whether each of them are supported by the core is implementation dependent. Moreover whether the ability to change the mode also depends on the chip family instance. Taking into account all of this we created a dedicated mm_config() method to detect and enable merging if it's supported. It is called for MIPS-type processors at CPU-probe stage and attempts to detect whether the write merging is available. If it's known to be supported and switchable, then switch on the full mode. Otherwise just perform the CP0.Config.MM field analysis. In addition there are platforms like InterAptiv/ProAptiv, which do have the MM bit field set by default, but having write-through cacheing unsupported makes write-merging also unsupported. In this case we just ignore the MM field value. Co-developed-by: Alexey Malahov Signed-off-by: Alexey Malahov Signed-off-by: Serge Semin Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Arnd Bergmann Cc: Rob Herring Cc: devicetree@vger.kernel.org Signed-off-by: Thomas Bogendoerfer

mips: Fix cpu_has_mips64r1/2 activation for MIPS32 CPUs

2020-05-22T07:11:15Z

Commit 1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA allows") updated the cpu_has_mips* macro to be replaced with a constant expression where it's possible. By mistake it wasn't done correctly for cpu_has_mips64r1/cpu_has_mips64r2 macro. They are defined to be replaced with conditional expression __isa_range_or_flag(), which means either ISA revision being within the range or the corresponding CPU options flag was set at the probe stage or both being true at the same time. But the ISA level value doesn't indicate whether the ISA is MIPS32 or MIPS64. Due to this if we select MIPS32r1 - MIPS32r5 architectures the __isa_range() macro will activate the cpu_has_mips64rX flags, which is incorrect. In order to fix the problem we make sure the 64bits CPU support is enabled by means of checking the flag cpu_has_64bits aside with proper ISA range and specific Revision flag being set. Fixes: 1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA allows") Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Arnd Bergmann Cc: Rob Herring Cc: devicetree@vger.kernel.org Signed-off-by: Thomas Bogendoerfer

mips: Add MIPS Release 5 support

2020-05-22T07:09:01Z

There are five MIPS32/64 architecture releases currently available: from 1 to 6 except fourth one, which was intentionally skipped. Three of them can be called as major: 1st, 2nd and 6th, that not only have some system level alterations, but also introduced significant core/ISA level updates. The rest of the MIPS architecture releases are minor. Even though they don't have as much ISA/system/core level changes as the major ones with respect to the previous releases, they still provide a set of updates (I'd say they were intended to be the intermediate releases before a major one) that might be useful for the kernel and user-level code, when activated by the kernel or compiler. In particular the following features were introduced or ended up being available at/after MIPS32/64 Release 5 architecture: + the last release of the misaligned memory access instructions, + virtualisation - VZ ASE - is optional component of the arch, + SIMD - MSA ASE - is optional component of the arch, + DSP ASE is optional component of the arch, + CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers) must be available if FPU is implemented, + CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits are available. + UFR/UNFR aliases to access CP0.Status.FR from user-space by means of ctc1/cfc1 instructions (enabled by CP0.Config5.UFR), + CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without accidentally clearing LL-bit when returning from an interrupt, exception, or error trap, + XPA feature together with extended versions of CPx registers is introduced, which needs to have mfhc0/mthc0 instructions available. So due to these changes GNU GCC provides an extended instructions set support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even though the architecture alteration isn't that big, it still worth to be taken into account by the kernel software. Finally we can't deny that some optimization/limitations might be found in future and implemented on some level in kernel or compiler. In this case having even intermediate MIPS architecture releases support would be more than useful. So the most of the changes provided by this commit can be split into either compile- or runtime configs related. The compile-time related changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5 configs and concern the code activating MIPSR2 or MIPSR6 already implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes concerns the features which are handled with respect to the MIPS ISA revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas these fields can be used to detect either r1 or r2 or r6 releases. But since we know which CPUs in fact support the R5 arch, we can manually set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate. Since XPA/EVA provide too complex alterationss and to have them used with MIPS32 Release 2 charged kernels (for compatibility with current platform configs) they are left to be setup as a separate kernel configs. Co-developed-by: Alexey Malahov Signed-off-by: Alexey Malahov Signed-off-by: Serge Semin Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Arnd Bergmann Cc: Rob Herring Cc: devicetree@vger.kernel.org Signed-off-by: Thomas Bogendoerfer

MIPS: remove cpu_has_64bit_addresses

2020-04-19T14:08:29Z

This macro is identical to CONFIG_64BIT, and using a Kconfig variable for the only places that checks them (the ioremap implementation) will simplify later patches in this series. Signed-off-by: Christoph Hellwig Signed-off-by: Thomas Bogendoerfer

MIPS: Add MAC2008 Support

2020-01-22T23:56:08Z

MAC2008 means the processor implemented IEEE754 style Fused MADD instruction. It was introduced in Release3 but removed in Release5. The toolchain support of MAC2008 have never landed except for Loongson processors. This patch aimed to disabled the MAC2008 if it's optional. For MAC2008 only processors, we corrected math-emu behavior to align with actual hardware behavior. Signed-off-by: Jiaxun Yang [paulburton@kernel.org: Fixup MIPSr2-r5 check in cpu_set_fpu_2008.] Signed-off-by: Paul Burton Cc: linux-mips@vger.kernel.org Cc: chenhc@lemote.com Cc: paul.burton@mips.com Cc: linux-kernel@vger.kernel.org

MIPS: tlbex: Remove cpu_has_local_ebase

2019-09-03T13:20:54Z

The cpu_has_local_ebase macro is, confusingly, not used to indicate whether the EBase register is local to a CPU or not. Instead it indicates whether we want to generate the TLB refill exception vector each time a CPU is brought online. Doing this makes little sense on any system, since we always use the same value for EBase & thus we cannot have different TLB refill exception handlers per CPU. Regenerating the code is not only pointless but also can be actively harmful, as commit 8759934e2b6b ("MIPS: Build uasm-generated code only once to avoid CPU Hotplug problem") described. That commit introduced cpu_has_local_ebase to disable the handler regeneration for Loongson machines, but this is by no means a Loongson-specific problem. Remove cpu_has_local_ebase & simply generate the TLB refill handler once during boot, just like the rest of the TLB exception handlers. Signed-off-by: Paul Burton Reviewed-by: Philippe Mathieu-Daudé Cc: linux-mips@vger.kernel.org

MIPS: Treat Loongson Extensions as ASEs

2019-08-26T10:42:40Z

Recently, binutils had split Loongson-3 Extensions into four ASEs: MMI, CAM, EXT, EXT2. This patch do the samething in kernel and expose them in cpuinfo so applications can probe supported ASEs at runtime. Signed-off-by: Jiaxun Yang Cc: Huacai Chen Cc: Yunqiang Su Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Paul Burton Cc: linux-mips@vger.kernel.org

MIPS: MemoryMapID (MMID) Support

2019-02-04T18:56:41Z

Introduce support for using MemoryMapIDs (MMIDs) as an alternative to Address Space IDs (ASIDs). The major difference between the two is that MMIDs are global - ie. an MMID uniquely identifies an address space across all coherent CPUs. In contrast ASIDs are non-global per-CPU IDs, wherein each address space is allocated a separate ASID for each CPU upon which it is used. This global namespace allows a new GINVT instruction be used to globally invalidate TLB entries associated with a particular MMID across all coherent CPUs in the system, removing the need for IPIs to invalidate entries with separate ASIDs on each CPU. The allocation scheme used here is largely borrowed from arm64 (see arch/arm64/mm/context.c). In essence we maintain a bitmap to track available MMIDs, and MMIDs in active use at the time of a rollover to a new MMID version are preserved in the new version. The allocation scheme requires efficient 64 bit atomics in order to perform reasonably, so this support depends upon CONFIG_GENERIC_ATOMIC64=n (ie. currently it will only be included in MIPS64 kernels). The first, and currently only, available CPU with support for MMIDs is the MIPS I6500. This CPU supports 16 bit MMIDs, and so for now we cap our MMIDs to 16 bits wide in order to prevent the bitmap growing to absurd sizes if any future CPU does implement 32 bit MMIDs as the architecture manuals suggest is recommended. When MMIDs are in use we also make use of GINVT instruction which is available due to the global nature of MMIDs. By executing a sequence of GINVT & SYNC 0x14 instructions we can avoid the overhead of an IPI to each remote CPU in many cases. One complication is that GINVT will invalidate wired entries (in all cases apart from type 0, which targets the entire TLB). In order to avoid GINVT invalidating any wired TLB entries we set up, we make sure to create those entries using a reserved MMID (0) that we never associate with any address space. Also of note is that KVM will require further work in order to support MMIDs & GINVT, since KVM is involved in allocating IDs for guests & in configuring the MMU. That work is not part of this patch, so for now when MMIDs are in use KVM is disabled. Signed-off-by: Paul Burton Cc: linux-mips@vger.kernel.org