- 13 May, 2016 40 commits
-
-
James Hogan authored
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:
James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13225/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
James Hogan authored
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:
-
James Hogan authored
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:
Matt Redfearn <matt.redfearn@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13223/Signed-off-by:
-
James Hogan authored
Add definitions for the bits & fields in the CP0_EBase register, and use them from a few different places in arch/mips which hardcoded these values. Signed-off-by:
-
Stephen Boyd authored
This flag is a no-op now (see commit 47b0eeb3 "clk: Deprecate CLK_IS_ROOT", 2016-02-02) so remove it. Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Cc: Manuel Lauss <manuel.lauss@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13134/Signed-off-by:
-
Stephen Boyd authored
This flag is a no-op now (see commit 47b0eeb3 "clk: Deprecate CLK_IS_ROOT", 2016-02-02) so remove it. Signed-off-by:
-
Aurelien Jarno authored
Octeon machines support running in little endian mode. U-Boot usually runs in big endian-mode. Therefore the initramfs is loaded in big endian mode, and the kernel later tries to access it in little endian mode. This patch fixes that by detecting byte swapped initramfs using either the CPIO header or the header from standard compression methods, and byte swaps it if needed. It first checks that the header doesn't match in the native endianness to avoid false detections. It uses the kernel decompress library so that we don't have to maintain the list of magics if some decompression methods are added to the kernel. Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Acked-by:
David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13219/Signed-off-by:
-
Florian Fainelli authored
Make BMIPS4380 and BMIPS5000 advertise support for RIXI through cpu_probe_broadcom(). bmips_cpu_setup() needs to be called shortly after that, during prom_init() in order to enable the proper Broadcom-specific register to turn on RIXI and the "rotr" instruction. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Cc: john@phrozen.org Cc: cernekee@gmail.com Cc: jon.fraser@broadcom.com Cc: pgynther@google.com Cc: paul.burton@imgtec.com Cc: ddaney.cavm@gmail.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12507/Signed-off-by:
-
Florian Fainelli authored
Some processors may not have the RIXI bit advertised in the Config3 register, not being a MIPS32R2 or R6 core, yet, they might be supporting it through a different way, which is overriden during vendor-specific cpu_probe(). Move the RIXI exceptions enabling after the vendor-specific cpu_probe() function has had a change to run and override the current CPU's options with MIPS_CPU_RIXI. Signed-off-by:
-
Florian Fainelli authored
Some processors, like Broadcom's BMIPS4380 and BMIPS5000 support RIXI and the "rotr" instruction, which can be used to get a slightly more efficient page table layout. Introduce a CONFIG_CPU_HAS_RIXI such that those cores can benefit from this feature. Perform the conditional check updates where relevant. Signed-off-by:
-
Paul Burton authored
XPA kernels hardcode for the presence of RIXI - the PTE format & its handling presume RI & XI bits. Make this dependence explicit by panicing if we run on a system that violates it. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Reviewed-by:
-
James Hogan authored
Performing an MTHC0 instruction without XPA being present will trigger a reserved instruction exception, therefore conditionalise the use of this instruction when building TLB handlers (build_update_entries()), and in __update_tlb(). This allows an XPA kernel to run on non XPA hardware without that instruction implemented, just like it can run on XPA capable hardware without XPA in use (with the noxpa kernel argument) or with XPA not configured in hardware. [paul.burton@imgtec.com: - Rebase atop other TLB work. - Add "mm" to subject. - Handle the __kmap_pgprot case.] Fixes: c5b36783 ("MIPS: Add support for XPA.") Signed-off-by:
-
Paul Burton authored
We can simplify build_update_entries by unifying the code for the 36 bit physical addressing with MIPS32 case with the general case, by using pte_off_ variables in all cases & handling the trivial _PAGE_GLOBAL_SHIFT == 0 case in build_convert_pte_to_entrylo. This leaves XPA as the only special case. Signed-off-by:
-
Paul Burton authored
The XPA case in iPTE_SW or's in software mode bits to the pte_low value (which is what actually ends up in the high 32 bits of EntryLo...). It does this presuming that only bits in the upper 16 bits of the 32 bit pte_low value will be set. Make this assumption explicit with a BUG_ON. A similar assumption is made for the hardware mode bits, which are or'd in with a single ori instruction. Make that assumption explicit with a BUG_ON too. Signed-off-by:
-
Paul Burton authored
Rather than hardcode a scratch register for the XPA case in iPTE_SW, pass one through from the work registers allocated by the caller. This allows for the XPA path to function correctly regardless of the work registers in use. Without doing this there are cases (where KScratch registers are unavailable) in which iPTE_SW will incorrectly clobber $1 despite it already being in use for the PTE or PTE pointer. Signed-off-by:
-
James Hogan authored
For XPA kernels build_update_entries() uses $1 (at) as a scratch register, but doesn't arrange for it to be preserved, so it will always be clobbered by the TLB refill exception. Although this register normally has a very short lifetime that doesn't cross memory accesses, TLB refills due to instruction fetches (either on a page boundary or after preemption) could clobber live data, and its easy to reproduce the clobber with a little bit of assembler code. Note that the use of a hardware page table walker will partly mask the problem, as the TLB refill handler will not always be invoked. This is fixed by avoiding the use of the extra scratch register. The pte_high parts (going into the lower half of the EntryLo registers) are loaded and manipulated separately so as to keep the PTE pointer around for the other halves (instead of storing in the scratch register), and the pte_low parts (going into the high half of the EntryLo registers) are masked with 0x00ffffff using an ext instruction (instead of loading 0x00ffffff into the scratch register and AND'ing). [paul.burton@imgtec.com: - Rebase atop other TLB work. - Use ext instead of an sll, srl sequence. - Use cpu_has_xpa instead of #ifdefs. - Modify commit subject to include "mm".] Fixes: c5b36783 ("MIPS: Add support for XPA.") Signed-off-by:
-
Paul Burton authored
There are 2 distinct cases in which a kernel for a MIPS32 CPU (CONFIG_CPU_MIPS32=y) may use 64 bit physical addresses (CONFIG_PHYS_ADDR_T_64BIT=y): - 36 bit physical addressing as used by RMI Alchemy & Netlogic XLP/XLR CPUs. - MIPS32r5 eXtended Physical Addressing (XPA). These 2 cases are distinct in that they require different behaviour from the kernel - the EntryLo registers have different formats. Until Linux v4.1 we only supported the first case, with code conditional upon the 2 aforementioned Kconfig variables being set. Commit c5b36783 ("MIPS: Add support for XPA.") added support for the second case, but did so by modifying the code that existed for the first case rather than treating the 2 cases as distinct. Since the EntryLo registers have different formats this breaks the 36 bit Alchemy/XLP/XLR case. Fix this by splitting the 2 cases, with XPA cases now being conditional upon CONFIG_XPA and the non-XPA case matching the code as it existed prior to commit c5b36783 ("MIPS: Add support for XPA."). Signed-off-by:Manuel Lauss <manuel.lauss@gmail.com> Tested-by:
-
Paul Burton authored
The same definition for pte_page is duplicated for the MIPS32 PHYS_ADDR_T_64BIT case & the generic case. Unify them by moving a single definition outside of preprocessor conditionals. Signed-off-by:
-
Paul Burton authored
Ever since support for RI/XI was implemented by commit 6dd9344c ("MIPS: Implement Read Inhibit/eXecute Inhibit") we've had a mixture of _PAGE_READ & _PAGE_NO_READ bits. Rather than keep both around, switch away from using _PAGE_READ to determine page presence & instead invert the use to _PAGE_NO_READ. Wherever we formerly had no definition for _PAGE_NO_READ, change what was _PAGE_READ to _PAGE_NO_READ. The end result is that we consistently use _PAGE_NO_READ to determine whether a page is readable, regardless of whether RI/XI is implemented. Signed-off-by:
-
Paul Burton authored
asm/pgtable-bits.h has grown to become an unreadable mess of #ifdef directives defining bits conditionally upon other bits all at the preprocessing stage, for no good reason. Instead of having quite so many #ifdef's, simply use enums to provide sequential numbering for bit shifts, without having to keep track manually of what the last bit defined was. Masks are defined separately, after the shifts, which allows for most of their definitions to be reused for all systems rather than duplicated. This patch is not intended to make any behavioural change to the code - all bits should be used in the same way they were before this patch. Signed-off-by:
-
Paul Burton authored
asm/pgtable-bits.h is included in 2 assembly files and thus has to ifdef around C code, however nothing defined by the header is used in either of the assembly files that include it. Remove the redundant inclusions such that asm/pgtable-bits.h doesn't need to #ifdef around C code, for cleanliness and in preparation for later patches which will add more C. Signed-off-by:
-
James Hogan authored
The hardware page table walker (HTW) configuration is broken on XPA kernels where XPA couldn't be enabled (either nohtw or the hardware doesn't support it). This is because the PWSize.PTEW field (PTE width) was only set to 8 bytes (an extra shift of 1) in config_htw_params() if PageGrain.ELPA (enable large physical addressing) is set. On an XPA kernel though the size of PTEs is fixed at 8 bytes regardless of whether XPA could actually be enabled. Fix the initialisation of this field based on sizeof(pte_t) instead. Fixes: c5b36783 ("MIPS: Add support for XPA.") Signed-off-by:
-
James Hogan authored
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:
-
Paul Burton authored
When emulating a jalr instruction with rd == $0, the code in isBranchInstr was incorrectly writing to GPR $0 which should actually always remain zeroed. This would lead to any further instructions emulated which use $0 operating on a bogus value until the task is next context switched, at which point the value of $0 in the task context would be restored to the correct zero by a store in SAVE_SOME. Fix this by not writing to rd if it is $0. Fixes: 102cedc3 ("MIPS: microMIPS: Floating point support.") Signed-off-by:
-
Paul Burton authored
The code in _sp_maddf (formerly ieee754sp_madd) appears to have been copied verbatim from ieee754sp_add, and although it's adding the unpacked "r" & "z" floats it kept using macros that operate on "x" & "y". This led to the addition being carried out incorrectly on some mismash of the product, accumulator & multiplicand fields. Typically this would lead to the assertions "ze == re" & "ze <= SP_EMAX" failing since ze & re hadn't been operated upon. Signed-off-by:
-
Paul Burton authored
A line incrementing the re variable was indented a level too deep in ieee754dp_mul, making the code unclear to read. Fix the indentation. This appears to have been copied verbatim along with the rest of the multiplication code to ieee754dp_maddf, now _dp_maddf, too so fix the indentation there too. Signed-off-by:
-
Paul Burton authored
A comment in ieee754dp_mul indicates that the code is about to perform a 32b x 32b multiplication & keep the high 32b of the result. It appears this was copied from the single-precision multiplication code, since the code actually goes on to perform a 64b x 64b multiplication & keep the high 64b of the result. Fix the comment to indicate 64b. It appears also that this comment was copied verbatim along with the rest of the multiplication code into ieee754dp_maddf, which has since been renamed _dp_maddf. Fix the same issue there. Signed-off-by:
-
Paul Burton authored
Introduce macros for handling the "z" argument to maddf & msubf, making its handling consistent with that of the "x" & "y" arguments rather than open-coding equivalents. Signed-off-by:
-
Paul Burton authored
The code for emulating MIPSr6 madd.d & msub.d instructions has previously been implemented as 2 different functions, namely ieee754dp_maddf & ieee754dp_msubf. The difference in behaviour of these 2 instructions is merely the sign of the product, so we can easily share the code implementing them. Do this for the double precision variant, removing the original ieee754dp_msubf in favor of reusing the code from ieee754dp_maddf. Signed-off-by:
-
Paul Burton authored
The code for emulating MIPSr6 madd.s & msub.s instructions has previously been implemented as 2 different functions, namely ieee754sp_maddf & ieee754sp_msubf. The difference in behaviour of these 2 instructions is merely the sign of the product, so we can easily share the code implementing them. Do this for the single precision variant, removing the original ieee754sp_msubf in favor of reusing the code from ieee754sp_maddf. Signed-off-by:
-
Paul Burton authored
Add support for emulating the MIPSr6 sel.fmt instruction, which was previously missing from the FPU emulation code. This instruction selects its result from 2 possible source registers, based upon bit 0 of the destination register, and is valid only for S (single) & D (double) data types. Signed-off-by:
-
Paul Burton authored
Declare the opcode for the MIPSr6 sel.fmt instruction, as fsel_op in order to match other FP op names. Signed-off-by:
-
Paul Burton authored
The conditions for branching when emulating the BC1EQZ & BC1NEZ instructions were backwards, leading to each of those instructions being treated as the other. Fix this by reversing the conditions, and clear up the code a little for readability & checkpatch. Fixes: c8a34581 ("MIPS: Emulate the BC1{EQ,NE}Z FPU instructions") Signed-off-by:
-
Paul Burton authored
The conditions for branching when emulating the BC1EQZ & BC1NEZ instructions were backwards, leading to each of those instructions being treated as the other. Fix this by reversing the conditions, and clear up the code a little for readability & checkpatch. Fixes: c909ca71 ("MIPS: math-emu: Emulate missing BC1{EQ,NE}Z instructions") Signed-off-by:
-
Rabin Vincent authored
Allow the builtin command line to be extended by what the bootloader passes in. For example, the bootloader can pass specific arguments depending on the boot mode, and these should override the defaults in the builtin cmdline. The default MIPS_CMDLINE_FROM_BOOTLOADER option prepends the bootloader's cmdline to the builtin cmdline so is not suitable for this purpose. Signed-off-by:
Rabin Vincent <rabinv@axis.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13181/Signed-off-by:
-
Rabin Vincent authored
The leading spaces don't affect functionality but are unnecessary. Signed-off-by:
-
James Hogan authored
Various branches and jumps in noreorder parts of genex.S don't have their delay slot instructions indented conventionally with the extra space. Fix these, as well as various other inconsistent whitespace problems in this file, such as spaces used after some opcodes instead of a tab. Signed-off-by:
-
Paul Burton authored
Add support for extended ASIDs as determined by the Config4.AE bit. Since the only supported CPUs known to implement this are Netlogic XLP and MIPS I6400, select this variable ASID support based upon CONFIG_CPU_XLP and CONFIG_CPU_MIPSR6. Signed-off-by:
-
Paul Burton authored
In preparation for supporting variable ASID masks, retrieve ASID masks using functions in asm/cpu-info.h which accept struct cpuinfo_mips. This will allow those functions to determine the ASID mask based upon the CPU in a later patch. This also allows for the r3k & r8k cases to be handled in Kconfig, which is arguably cleaner than the previous #ifdefs. Signed-off-by:
-
James Hogan authored
Now that the at register ($1) is no longer saved by __kvm_mips_vcpu_run(), relax the noat assembler directive so that it only applies around code where at is restored before entering guest, and saved after exiting guest. Signed-off-by:
-
