OpenE2K
/
linux
6
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
linux/arch/mips/lib/dump_tlb.c

201 lines
5.4 KiB
C
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 15:07:57 +01:00
// SPDX-License-Identifier: GPL-2.0
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
/*
* Dump R4x00 TLB for debugging purposes.
*
* Copyright (C) 1994, 1995 by Waldorf Electronics, written by Ralf Baechle.
* Copyright (C) 1999 by Silicon Graphics, Inc.
*/
#include <linux/kernel.h>
#include <linux/mm.h>
MIPS: dump_tlb: Use tlbr hazard macros Use the new tlb read hazard macros from <asm/hazards.h> rather than the local BARRIER() macro which uses 7 ops regardless of the kernel configuration. We use mtc0_tlbr_hazard for the hazard between mtc0 to the index register and the tlbr, and tlb_read_hazard for the hazard between the tlbr and the mfc0 of the TLB registers written by tlbr. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10074/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:32 +02:00
#include <asm/hazards.h>
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
#include <asm/mipsregs.h>
MIPS: MemoryMapID (MMID) Support 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 <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org
2019-02-02 02:43:28 +01:00
#include <asm/mmu_context.h>
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
#include <asm/page.h>
#include <asm/pgtable.h>
[MIPS] Cleanup tlbdebug.h Also include tlbdebug.h in dump_tlb.c and r3k_dump_tlb.c. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2007-07-11 17:51:00 +02:00
#include <asm/tlbdebug.h>
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
MIPS: Refactor dumping of TLB registers for r3k/r4k The TLB registers are dumped in a couble of places: - sysrq_tlbdump_single() - when dumping TLB state. - do_mcheck() - in response to a machine check error. The main TLB registers also differ between r3k and r4k, but r4k appears to be assumed. Refactor this code into a dump_tlb_regs() function, implemented for both r3k and r4k, and used by both of the above functions. Fixes: d1e9a4f54735 ("MIPS: Add SysRq operation to dump TLBs on all CPUs") Suggested-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10721/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-15 17:17:43 +02:00
void dump_tlb_regs(void)
{
const int field = 2 * sizeof(unsigned long);
pr_info("Index : %0x\n", read_c0_index());
pr_info("PageMask : %0x\n", read_c0_pagemask());
MIPS: Print GuestCtl1 on machine check exception The GuestCtl1 CP0 register can contain the GuestID used for root TLB operations, which affects TLB matching. The other TLB registers are already dumped out to the log on a machine check exception due to multiple matching TLB entries, so also dump the value of the GuestCtl1 register if GuestIDs are supported. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13232/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-05-11 16:50:32 +02:00
if (cpu_has_guestid)
pr_info("GuestCtl1: %0x\n", read_c0_guestctl1());
MIPS: Refactor dumping of TLB registers for r3k/r4k The TLB registers are dumped in a couble of places: - sysrq_tlbdump_single() - when dumping TLB state. - do_mcheck() - in response to a machine check error. The main TLB registers also differ between r3k and r4k, but r4k appears to be assumed. Refactor this code into a dump_tlb_regs() function, implemented for both r3k and r4k, and used by both of the above functions. Fixes: d1e9a4f54735 ("MIPS: Add SysRq operation to dump TLBs on all CPUs") Suggested-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10721/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-15 17:17:43 +02:00
pr_info("EntryHi : %0*lx\n", field, read_c0_entryhi());
pr_info("EntryLo0 : %0*lx\n", field, read_c0_entrylo0());
pr_info("EntryLo1 : %0*lx\n", field, read_c0_entrylo1());
pr_info("Wired : %0x\n", read_c0_wired());
MIPS: dump_tlb: Dump FrameMask register if exists The FrameMask register is relevant to the TLB so it should be dumped by dump_tlb_regs(), however it is only present in certain cores (r10000, r12000, r14000, r16000). Add dumping of it, conditional upon current_cpu_type(). Suggested-by: Joshua Kinard <kumba@gentoo.org> Suggested-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Joshua Kinard <kumba@gentoo.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10724/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-15 17:17:46 +02:00
switch (current_cpu_type()) {
case CPU_R10000:
case CPU_R12000:
case CPU_R14000:
case CPU_R16000:
pr_info("FrameMask: %0x\n", read_c0_framemask());
break;
}
MIPS: dump_tlb: Only dump PageGrain if interesting The PageGrain register may not exist if certain architectural features aren't present, therefore only print out its value when dumping the TLB registers if it is expected to contain fields relevant to the TLB. Fixes: d1e9a4f54735 ("MIPS: Add SysRq operation to dump TLBs on all CPUs") Reported-by: Joshua Kinard <kumba@gentoo.org> Reported-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Joshua Kinard <kumba@gentoo.org> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10723/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-15 17:17:45 +02:00
if (cpu_has_small_pages || cpu_has_rixi || cpu_has_xpa)
pr_info("PageGrain: %0x\n", read_c0_pagegrain());
MIPS: Refactor dumping of TLB registers for r3k/r4k The TLB registers are dumped in a couble of places: - sysrq_tlbdump_single() - when dumping TLB state. - do_mcheck() - in response to a machine check error. The main TLB registers also differ between r3k and r4k, but r4k appears to be assumed. Refactor this code into a dump_tlb_regs() function, implemented for both r3k and r4k, and used by both of the above functions. Fixes: d1e9a4f54735 ("MIPS: Add SysRq operation to dump TLBs on all CPUs") Suggested-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10721/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-15 17:17:43 +02:00
if (cpu_has_htw) {
pr_info("PWField : %0*lx\n", field, read_c0_pwfield());
pr_info("PWSize : %0*lx\n", field, read_c0_pwsize());
pr_info("PWCtl : %0x\n", read_c0_pwctl());
}
}
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
static inline const char *msk2str(unsigned int mask)
{
switch (mask) {
case PM_4K: return "4kb";
case PM_16K: return "16kb";
case PM_64K: return "64kb";
case PM_256K: return "256kb";
MIPS: Cavium: Add support for 8k and 32k page sizes. Beyond the requirements of the architecture standard Cavium also supports 8k and 32k pages. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: David Daney <ddaney@caviumnetworks.com>
2009-04-02 14:07:10 +02:00
#ifdef CONFIG_CPU_CAVIUM_OCTEON
case PM_8K: return "8kb";
case PM_32K: return "32kb";
case PM_128K: return "128kb";
case PM_512K: return "512kb";
case PM_2M: return "2Mb";
case PM_8M: return "8Mb";
case PM_32M: return "32Mb";
#endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
#ifndef CONFIG_CPU_VR41XX
case PM_1M: return "1Mb";
case PM_4M: return "4Mb";
case PM_16M: return "16Mb";
case PM_64M: return "64Mb";
case PM_256M: return "256Mb";
MIPS: Add CONFIG_CPU_R5500 for NEC VR5500 series processors We already have sufficient infrastructure to support VR5500 and VR5500A series processors. Here's a Makefile support to make it selectable by ports, and enable it for NEC EMMA2RH Markeins board. This patch also fixes a confused target help, and adds 1Gb PageMask bits supported by VR5500 and its variants. Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi@necel.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2008-10-23 18:27:57 +02:00
case PM_1G: return "1Gb";
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
#endif
}
[MIPS] Unify dump_tlb Unify lib-{32,64}/dump_tlb.c into lib/dump_tlb.c and move lib-32/r3k_dump_tlb.c to lib directory. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2007-06-01 17:21:30 +02:00
return "";
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
}
[MIPS] Remove unused dump_tlb functions Remove unused dump_tlb functions and cleanup some includes. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2007-06-01 17:30:25 +02:00
static void dump_tlb(int first, int last)
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
{
MIPS: MemoryMapID (MMID) Support 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 <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org
2019-02-02 02:43:28 +01:00
unsigned long s_entryhi, entryhi, asid, mmid;
MIPS: dump_tlb: Take RI/XI bits into account The RI/XI bits when present are above the PFN field in the EntryLo registers, at bits 63,62 when read with dmfc0, and bits 31,30 when read with mfc0. This makes them appear as part of the physical address, since the other bits are masked with PAGE_MASK, for example: Index: 253 pgmask=16kb va=77b18000 asid=75 [pa=1000744000 c=5 d=1 v=1 g=0] [pa=100134c000 c=5 d=1 v=1 g=0] The physical addresses have bit 36 set, which corresponds to bit 30 of EntryLo1, the XI bit. Explicitly mask off the RI and XI bits from the printed physical address, and print the RI and XI bits separately if they exist, giving output more like this: Index: 226 pgmask=16kb va=77be0000 asid=79 [ri=0 xi=1 pa=01288000 c=5 d=1 v=1 g=0] [ri=0 xi=0 pa=010e4000 c=5 d=0 v=1 g=0] Cc: linux-mips@linux-mips.org Cc: James Hogan <james.hogan@imgtec.com> Cc: David Daney <ddaney@caviumnetworks.com> Patchwork: https://patchwork.linux-mips.org/patch/10080/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:37 +02:00
unsigned long long entrylo0, entrylo1, pa;
MIPS: dump_tlb: Preserve and dump GuestID The GuestID for root TLB operations (GuestCtl1.RID) is modified by TLB reads, so needs preserving by dump_tlb() like the ASID field of EntryHi. Also dump the GuestID of each entry if it exists alongside the ASID, as it forms an important part of the TLB entry when VZ guests are used. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13230/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-05-11 16:50:31 +02:00
unsigned int s_index, s_pagemask, s_guestctl1 = 0;
unsigned int pagemask, guestctl1 = 0, c0, c1, i;
MIPS: Retrieve ASID masks using function accepting struct cpuinfo_mips 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: Paul Burton <paul.burton@imgtec.com> Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/13210/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-05-06 15:36:23 +02:00
unsigned long asidmask = cpu_asid_mask(&current_cpu_data);
int asidwidth = DIV_ROUND_UP(ilog2(asidmask) + 1, 4);
MIPS: MemoryMapID (MMID) Support 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 <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org
2019-02-02 02:43:28 +01:00
unsigned long uninitialized_var(s_mmid);
MIPS: dump_tlb: Refactor TLB matching Refactor the TLB matching code in dump_tlb() slightly so that the conditions which can cause a TLB entry to be skipped can be more easily extended. This should prevent the match condition getting unwieldy once it is updated to take further conditions into account. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10081/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:33 +02:00
#ifdef CONFIG_32BIT
MIPS: dump_tlb: Take XPA into account XPA extends the physical addresses on MIPS32, including the EntryLo registers. Update dump_tlb() to concatenate the PFNX field from the high end of the EntryLo registers (as read by mfhc0). The width of physical and virtual addresses are also separated to show only 8 nibbles of virtual but 11 nibbles of physical with XPA. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10077/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:38 +02:00
bool xpa = cpu_has_xpa && (read_c0_pagegrain() & PG_ELPA);
int pwidth = xpa ? 11 : 8;
int vwidth = 8;
MIPS: dump_tlb: Refactor TLB matching Refactor the TLB matching code in dump_tlb() slightly so that the conditions which can cause a TLB entry to be skipped can be more easily extended. This should prevent the match condition getting unwieldy once it is updated to take further conditions into account. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10081/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:33 +02:00
#else
MIPS: dump_tlb: Take XPA into account XPA extends the physical addresses on MIPS32, including the EntryLo registers. Update dump_tlb() to concatenate the PFNX field from the high end of the EntryLo registers (as read by mfhc0). The width of physical and virtual addresses are also separated to show only 8 nibbles of virtual but 11 nibbles of physical with XPA. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10077/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:38 +02:00
bool xpa = false;
int pwidth = 11;
int vwidth = 11;
MIPS: dump_tlb: Refactor TLB matching Refactor the TLB matching code in dump_tlb() slightly so that the conditions which can cause a TLB entry to be skipped can be more easily extended. This should prevent the match condition getting unwieldy once it is updated to take further conditions into account. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10081/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:33 +02:00
#endif
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
MIPS: Restore pagemask after dumping the TLB. Or bad things might happen if the last TLB entry isn't a basic size page. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2012-10-17 01:01:20 +02:00
s_pagemask = read_c0_pagemask();
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
s_entryhi = read_c0_entryhi();
s_index = read_c0_index();
MIPS: MemoryMapID (MMID) Support 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 <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org
2019-02-02 02:43:28 +01:00
if (cpu_has_mmid)
asid = s_mmid = read_c0_memorymapid();
else
asid = s_entryhi & asidmask;
MIPS: dump_tlb: Preserve and dump GuestID The GuestID for root TLB operations (GuestCtl1.RID) is modified by TLB reads, so needs preserving by dump_tlb() like the ASID field of EntryHi. Also dump the GuestID of each entry if it exists alongside the ASID, as it forms an important part of the TLB entry when VZ guests are used. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13230/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-05-11 16:50:31 +02:00
if (cpu_has_guestid)
s_guestctl1 = read_c0_guestctl1();
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
for (i = first; i <= last; i++) {
write_c0_index(i);
MIPS: dump_tlb: Use tlbr hazard macros Use the new tlb read hazard macros from <asm/hazards.h> rather than the local BARRIER() macro which uses 7 ops regardless of the kernel configuration. We use mtc0_tlbr_hazard for the hazard between mtc0 to the index register and the tlbr, and tlb_read_hazard for the hazard between the tlbr and the mfc0 of the TLB registers written by tlbr. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10074/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:32 +02:00
mtc0_tlbr_hazard();
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
tlb_read();
MIPS: dump_tlb: Use tlbr hazard macros Use the new tlb read hazard macros from <asm/hazards.h> rather than the local BARRIER() macro which uses 7 ops regardless of the kernel configuration. We use mtc0_tlbr_hazard for the hazard between mtc0 to the index register and the tlbr, and tlb_read_hazard for the hazard between the tlbr and the mfc0 of the TLB registers written by tlbr. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10074/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:32 +02:00
tlb_read_hazard();
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
pagemask = read_c0_pagemask();
MIPS: Whitespace cleanup. Having received another series of whitespace patches I decided to do this once and for all rather than dealing with this kind of patches trickling in forever. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2013-01-22 12:59:30 +01:00
entryhi = read_c0_entryhi();
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
entrylo0 = read_c0_entrylo0();
entrylo1 = read_c0_entrylo1();
MIPS: MemoryMapID (MMID) Support 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 <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org
2019-02-02 02:43:28 +01:00
if (cpu_has_mmid)
mmid = read_c0_memorymapid();
else
mmid = entryhi & asidmask;
MIPS: dump_tlb: Preserve and dump GuestID The GuestID for root TLB operations (GuestCtl1.RID) is modified by TLB reads, so needs preserving by dump_tlb() like the ASID field of EntryHi. Also dump the GuestID of each entry if it exists alongside the ASID, as it forms an important part of the TLB entry when VZ guests are used. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13230/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-05-11 16:50:31 +02:00
if (cpu_has_guestid)
guestctl1 = read_c0_guestctl1();
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
MIPS: dump_tlb: Take EHINV bit into account The EHINV bit in EntryHi allows a TLB entry to be properly marked invalid so that EntryHi doesn't have to be set to a unique value to avoid machine check exceptions due to multiple matching entries. Unfortunately dump_tlb() doesn't take this into account so it will print all the uninteresting invalid TLB entries if the current ASID happens to be 00. Therefore add a condition to skip entries which are marked invalid with the EHINV bit. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10076/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:36 +02:00
/* EHINV bit marks entire entry as invalid */
if (cpu_has_tlbinv && entryhi & MIPS_ENTRYHI_EHINV)
continue;
MIPS: dump_tlb: Refactor TLB matching Refactor the TLB matching code in dump_tlb() slightly so that the conditions which can cause a TLB entry to be skipped can be more easily extended. This should prevent the match condition getting unwieldy once it is updated to take further conditions into account. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10081/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:33 +02:00
/*
* Prior to tlbinv, unused entries have a virtual address of
* CKSEG0.
*/
if ((entryhi & ~0x1ffffUL) == CKSEG0)
continue;
MIPS: dump_tlb: Take global bit into account The TLB only matches the ASID when the global bit isn't set, so dump_tlb() shouldn't really be skipping global entries just because the ASID doesn't match. Fix the condition to read the TLB entry's global bit from EntryLo0. Note that after a TLB read the global bits in both EntryLo registers reflect the same global bit in the TLB entry. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10079/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:35 +02:00
/*
* ASID takes effect in absence of G (global) bit.
* We check both G bits, even though architecturally they should
* match one another, because some revisions of the SB1 core may
* leave only a single G bit set after a machine check exception
* due to duplicate TLB entry.
*/
MIPS: MemoryMapID (MMID) Support 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 <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org
2019-02-02 02:43:28 +01:00
if (!((entrylo0 | entrylo1) & ENTRYLO_G) && (mmid != asid))
MIPS: dump_tlb: Refactor TLB matching Refactor the TLB matching code in dump_tlb() slightly so that the conditions which can cause a TLB entry to be skipped can be more easily extended. This should prevent the match condition getting unwieldy once it is updated to take further conditions into account. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10081/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:33 +02:00
continue;
/*
* Only print entries in use
*/
printk("Index: %2d pgmask=%s ", i, msk2str(pagemask));
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
MIPS: Rearrange ENTRYLO field definitions The generic field definitions (i.e. present before MIPS32/MIPS64) in mipsregs.h are conventionally not prefixed with MIPS_, so rename the recently added MIPS_ENTRYLO_* definitions for the G, V, D, and C fields to ENTRYLO_*. Also rearrange to put the EntryLo and EntryHi definitions in the right place in the file. Fixes: 8ab6abcb6aa4 ("MIPS: mipsregs.h: Add EntryLo bit definitions") Reported-by: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10725/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-07-15 17:17:47 +02:00
c0 = (entrylo0 & ENTRYLO_C) >> ENTRYLO_C_SHIFT;
c1 = (entrylo1 & ENTRYLO_C) >> ENTRYLO_C_SHIFT;
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
MIPS: dump_tlb: Fix printk continuations Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") the output from TLB dumps on MIPS has been pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to provide the appropriate markers & restore the expected output. Continuation is also used for the second line of each TLB entry printed in dump_tlb.c even though it has a newline, since it is a continuation of the interpretation of the same TLB entry. For example: [ 46.371884] Index: 0 pgmask=16kb va=77654000 asid=73 gid=00 [ri=0 xi=0 pa=ffc18000 c=5 d=0 v=1 g=0] [ri=0 xi=0 pa=ffc1c000 c=5 d=0 v=1 g=0] [ 46.385380] Index: 12 pgmask=16kb va=004b4000 asid=73 gid=00 [ri=0 xi=0 pa=00000000 c=0 d=0 v=0 g=0] [ri=0 xi=0 pa=ffb00000 c=5 d=1 v=1 g=0] Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Maciej W. Rozycki <macro@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14444/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-10-21 21:06:40 +02:00
pr_cont("va=%0*lx asid=%0*lx",
vwidth, (entryhi & ~0x1fffUL),
MIPS: MemoryMapID (MMID) Support 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 <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org
2019-02-02 02:43:28 +01:00
asidwidth, mmid);
MIPS: dump_tlb: Preserve and dump GuestID The GuestID for root TLB operations (GuestCtl1.RID) is modified by TLB reads, so needs preserving by dump_tlb() like the ASID field of EntryHi. Also dump the GuestID of each entry if it exists alongside the ASID, as it forms an important part of the TLB entry when VZ guests are used. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13230/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-05-11 16:50:31 +02:00
if (cpu_has_guestid)
MIPS: dump_tlb: Fix printk continuations Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") the output from TLB dumps on MIPS has been pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to provide the appropriate markers & restore the expected output. Continuation is also used for the second line of each TLB entry printed in dump_tlb.c even though it has a newline, since it is a continuation of the interpretation of the same TLB entry. For example: [ 46.371884] Index: 0 pgmask=16kb va=77654000 asid=73 gid=00 [ri=0 xi=0 pa=ffc18000 c=5 d=0 v=1 g=0] [ri=0 xi=0 pa=ffc1c000 c=5 d=0 v=1 g=0] [ 46.385380] Index: 12 pgmask=16kb va=004b4000 asid=73 gid=00 [ri=0 xi=0 pa=00000000 c=0 d=0 v=0 g=0] [ri=0 xi=0 pa=ffb00000 c=5 d=1 v=1 g=0] Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Maciej W. Rozycki <macro@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14444/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-10-21 21:06:40 +02:00
pr_cont(" gid=%02lx",
(guestctl1 & MIPS_GCTL1_RID)
MIPS: dump_tlb: Preserve and dump GuestID The GuestID for root TLB operations (GuestCtl1.RID) is modified by TLB reads, so needs preserving by dump_tlb() like the ASID field of EntryHi. Also dump the GuestID of each entry if it exists alongside the ASID, as it forms an important part of the TLB entry when VZ guests are used. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13230/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-05-11 16:50:31 +02:00
>> MIPS_GCTL1_RID_SHIFT);
MIPS: dump_tlb: Take RI/XI bits into account The RI/XI bits when present are above the PFN field in the EntryLo registers, at bits 63,62 when read with dmfc0, and bits 31,30 when read with mfc0. This makes them appear as part of the physical address, since the other bits are masked with PAGE_MASK, for example: Index: 253 pgmask=16kb va=77b18000 asid=75 [pa=1000744000 c=5 d=1 v=1 g=0] [pa=100134c000 c=5 d=1 v=1 g=0] The physical addresses have bit 36 set, which corresponds to bit 30 of EntryLo1, the XI bit. Explicitly mask off the RI and XI bits from the printed physical address, and print the RI and XI bits separately if they exist, giving output more like this: Index: 226 pgmask=16kb va=77be0000 asid=79 [ri=0 xi=1 pa=01288000 c=5 d=1 v=1 g=0] [ri=0 xi=0 pa=010e4000 c=5 d=0 v=1 g=0] Cc: linux-mips@linux-mips.org Cc: James Hogan <james.hogan@imgtec.com> Cc: David Daney <ddaney@caviumnetworks.com> Patchwork: https://patchwork.linux-mips.org/patch/10080/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:37 +02:00
/* RI/XI are in awkward places, so mask them off separately */
pa = entrylo0 & ~(MIPS_ENTRYLO_RI | MIPS_ENTRYLO_XI);
MIPS: dump_tlb: Take XPA into account XPA extends the physical addresses on MIPS32, including the EntryLo registers. Update dump_tlb() to concatenate the PFNX field from the high end of the EntryLo registers (as read by mfhc0). The width of physical and virtual addresses are also separated to show only 8 nibbles of virtual but 11 nibbles of physical with XPA. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10077/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:38 +02:00
if (xpa)
pa |= (unsigned long long)readx_c0_entrylo0() << 30;
MIPS: dump_tlb: Take RI/XI bits into account The RI/XI bits when present are above the PFN field in the EntryLo registers, at bits 63,62 when read with dmfc0, and bits 31,30 when read with mfc0. This makes them appear as part of the physical address, since the other bits are masked with PAGE_MASK, for example: Index: 253 pgmask=16kb va=77b18000 asid=75 [pa=1000744000 c=5 d=1 v=1 g=0] [pa=100134c000 c=5 d=1 v=1 g=0] The physical addresses have bit 36 set, which corresponds to bit 30 of EntryLo1, the XI bit. Explicitly mask off the RI and XI bits from the printed physical address, and print the RI and XI bits separately if they exist, giving output more like this: Index: 226 pgmask=16kb va=77be0000 asid=79 [ri=0 xi=1 pa=01288000 c=5 d=1 v=1 g=0] [ri=0 xi=0 pa=010e4000 c=5 d=0 v=1 g=0] Cc: linux-mips@linux-mips.org Cc: James Hogan <james.hogan@imgtec.com> Cc: David Daney <ddaney@caviumnetworks.com> Patchwork: https://patchwork.linux-mips.org/patch/10080/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:37 +02:00
pa = (pa << 6) & PAGE_MASK;
MIPS: dump_tlb: Fix printk continuations Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") the output from TLB dumps on MIPS has been pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to provide the appropriate markers & restore the expected output. Continuation is also used for the second line of each TLB entry printed in dump_tlb.c even though it has a newline, since it is a continuation of the interpretation of the same TLB entry. For example: [ 46.371884] Index: 0 pgmask=16kb va=77654000 asid=73 gid=00 [ri=0 xi=0 pa=ffc18000 c=5 d=0 v=1 g=0] [ri=0 xi=0 pa=ffc1c000 c=5 d=0 v=1 g=0] [ 46.385380] Index: 12 pgmask=16kb va=004b4000 asid=73 gid=00 [ri=0 xi=0 pa=00000000 c=0 d=0 v=0 g=0] [ri=0 xi=0 pa=ffb00000 c=5 d=1 v=1 g=0] Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Maciej W. Rozycki <macro@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14444/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-10-21 21:06:40 +02:00
pr_cont("\n\t[");
MIPS: dump_tlb: Take RI/XI bits into account The RI/XI bits when present are above the PFN field in the EntryLo registers, at bits 63,62 when read with dmfc0, and bits 31,30 when read with mfc0. This makes them appear as part of the physical address, since the other bits are masked with PAGE_MASK, for example: Index: 253 pgmask=16kb va=77b18000 asid=75 [pa=1000744000 c=5 d=1 v=1 g=0] [pa=100134c000 c=5 d=1 v=1 g=0] The physical addresses have bit 36 set, which corresponds to bit 30 of EntryLo1, the XI bit. Explicitly mask off the RI and XI bits from the printed physical address, and print the RI and XI bits separately if they exist, giving output more like this: Index: 226 pgmask=16kb va=77be0000 asid=79 [ri=0 xi=1 pa=01288000 c=5 d=1 v=1 g=0] [ri=0 xi=0 pa=010e4000 c=5 d=0 v=1 g=0] Cc: linux-mips@linux-mips.org Cc: James Hogan <james.hogan@imgtec.com> Cc: David Daney <ddaney@caviumnetworks.com> Patchwork: https://patchwork.linux-mips.org/patch/10080/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:37 +02:00
if (cpu_has_rixi)
MIPS: dump_tlb: Fix printk continuations Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") the output from TLB dumps on MIPS has been pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to provide the appropriate markers & restore the expected output. Continuation is also used for the second line of each TLB entry printed in dump_tlb.c even though it has a newline, since it is a continuation of the interpretation of the same TLB entry. For example: [ 46.371884] Index: 0 pgmask=16kb va=77654000 asid=73 gid=00 [ri=0 xi=0 pa=ffc18000 c=5 d=0 v=1 g=0] [ri=0 xi=0 pa=ffc1c000 c=5 d=0 v=1 g=0] [ 46.385380] Index: 12 pgmask=16kb va=004b4000 asid=73 gid=00 [ri=0 xi=0 pa=00000000 c=0 d=0 v=0 g=0] [ri=0 xi=0 pa=ffb00000 c=5 d=1 v=1 g=0] Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Maciej W. Rozycki <macro@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14444/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-10-21 21:06:40 +02:00
pr_cont("ri=%d xi=%d ",
(entrylo0 & MIPS_ENTRYLO_RI) ? 1 : 0,
(entrylo0 & MIPS_ENTRYLO_XI) ? 1 : 0);
pr_cont("pa=%0*llx c=%d d=%d v=%d g=%d] [",
pwidth, pa, c0,
(entrylo0 & ENTRYLO_D) ? 1 : 0,
(entrylo0 & ENTRYLO_V) ? 1 : 0,
(entrylo0 & ENTRYLO_G) ? 1 : 0);
MIPS: dump_tlb: Take RI/XI bits into account The RI/XI bits when present are above the PFN field in the EntryLo registers, at bits 63,62 when read with dmfc0, and bits 31,30 when read with mfc0. This makes them appear as part of the physical address, since the other bits are masked with PAGE_MASK, for example: Index: 253 pgmask=16kb va=77b18000 asid=75 [pa=1000744000 c=5 d=1 v=1 g=0] [pa=100134c000 c=5 d=1 v=1 g=0] The physical addresses have bit 36 set, which corresponds to bit 30 of EntryLo1, the XI bit. Explicitly mask off the RI and XI bits from the printed physical address, and print the RI and XI bits separately if they exist, giving output more like this: Index: 226 pgmask=16kb va=77be0000 asid=79 [ri=0 xi=1 pa=01288000 c=5 d=1 v=1 g=0] [ri=0 xi=0 pa=010e4000 c=5 d=0 v=1 g=0] Cc: linux-mips@linux-mips.org Cc: James Hogan <james.hogan@imgtec.com> Cc: David Daney <ddaney@caviumnetworks.com> Patchwork: https://patchwork.linux-mips.org/patch/10080/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:37 +02:00
/* RI/XI are in awkward places, so mask them off separately */
pa = entrylo1 & ~(MIPS_ENTRYLO_RI | MIPS_ENTRYLO_XI);
MIPS: dump_tlb: Take XPA into account XPA extends the physical addresses on MIPS32, including the EntryLo registers. Update dump_tlb() to concatenate the PFNX field from the high end of the EntryLo registers (as read by mfhc0). The width of physical and virtual addresses are also separated to show only 8 nibbles of virtual but 11 nibbles of physical with XPA. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/10077/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:38 +02:00
if (xpa)
pa |= (unsigned long long)readx_c0_entrylo1() << 30;
MIPS: dump_tlb: Take RI/XI bits into account The RI/XI bits when present are above the PFN field in the EntryLo registers, at bits 63,62 when read with dmfc0, and bits 31,30 when read with mfc0. This makes them appear as part of the physical address, since the other bits are masked with PAGE_MASK, for example: Index: 253 pgmask=16kb va=77b18000 asid=75 [pa=1000744000 c=5 d=1 v=1 g=0] [pa=100134c000 c=5 d=1 v=1 g=0] The physical addresses have bit 36 set, which corresponds to bit 30 of EntryLo1, the XI bit. Explicitly mask off the RI and XI bits from the printed physical address, and print the RI and XI bits separately if they exist, giving output more like this: Index: 226 pgmask=16kb va=77be0000 asid=79 [ri=0 xi=1 pa=01288000 c=5 d=1 v=1 g=0] [ri=0 xi=0 pa=010e4000 c=5 d=0 v=1 g=0] Cc: linux-mips@linux-mips.org Cc: James Hogan <james.hogan@imgtec.com> Cc: David Daney <ddaney@caviumnetworks.com> Patchwork: https://patchwork.linux-mips.org/patch/10080/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-05-19 10:50:37 +02:00
pa = (pa << 6) & PAGE_MASK;
if (cpu_has_rixi)
MIPS: dump_tlb: Fix printk continuations Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") the output from TLB dumps on MIPS has been pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to provide the appropriate markers & restore the expected output. Continuation is also used for the second line of each TLB entry printed in dump_tlb.c even though it has a newline, since it is a continuation of the interpretation of the same TLB entry. For example: [ 46.371884] Index: 0 pgmask=16kb va=77654000 asid=73 gid=00 [ri=0 xi=0 pa=ffc18000 c=5 d=0 v=1 g=0] [ri=0 xi=0 pa=ffc1c000 c=5 d=0 v=1 g=0] [ 46.385380] Index: 12 pgmask=16kb va=004b4000 asid=73 gid=00 [ri=0 xi=0 pa=00000000 c=0 d=0 v=0 g=0] [ri=0 xi=0 pa=ffb00000 c=5 d=1 v=1 g=0] Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Maciej W. Rozycki <macro@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14444/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-10-21 21:06:40 +02:00
pr_cont("ri=%d xi=%d ",
(entrylo1 & MIPS_ENTRYLO_RI) ? 1 : 0,
(entrylo1 & MIPS_ENTRYLO_XI) ? 1 : 0);
pr_cont("pa=%0*llx c=%d d=%d v=%d g=%d]\n",
pwidth, pa, c1,
(entrylo1 & ENTRYLO_D) ? 1 : 0,
(entrylo1 & ENTRYLO_V) ? 1 : 0,
(entrylo1 & ENTRYLO_G) ? 1 : 0);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
}
printk("\n");
write_c0_entryhi(s_entryhi);
write_c0_index(s_index);
MIPS: Restore pagemask after dumping the TLB. Or bad things might happen if the last TLB entry isn't a basic size page. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2012-10-17 01:01:20 +02:00
write_c0_pagemask(s_pagemask);
MIPS: dump_tlb: Preserve and dump GuestID The GuestID for root TLB operations (GuestCtl1.RID) is modified by TLB reads, so needs preserving by dump_tlb() like the ASID field of EntryHi. Also dump the GuestID of each entry if it exists alongside the ASID, as it forms an important part of the TLB entry when VZ guests are used. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/13230/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-05-11 16:50:31 +02:00
if (cpu_has_guestid)
write_c0_guestctl1(s_guestctl1);
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-17 00:20:36 +02:00
}
void dump_tlb_all(void)
{
dump_tlb(0, current_cpu_data.tlbsize - 1);
}