LoongArch Reference Manual. Volume 1: Basic Architecture (Version 1.02) - page 8
The Cache object indicated by op[2:0] is in the same order as the Cache identified in CPUCFG10. For
example, when CPUCFG10=0x02C3D, op[2:0]=0 indicates operation of the first-level private instruction
Cache, op[2:0]=1 indicates operation of the first-level private data Cache, op[2:0]=2 indicates
operation of the second-level private mixed Cache, and op[2:0]=3 indicates operation of the third-level
shared mixed Cache.
op[4:3]=0 is used for Cache initialization (StoreTag), mainly to write the contents of the CSR.CTAG to
the tag of the specified Cache row using direct address indexing. Suppose the Cache to be accessed has
(1<<Way) ways, each ways has (1<<Index) Cache line, and each Cache line size is (1<<0ffset) bytes,
then the direct address indexing method means that the VA[Index+offset1.0ffset] of the VA[Way-
1:0] way of the Cache is [operated: 0ffset] line of the Cache.
op[4:3]=1 means that the cache-consistency (Index Invalidate / Invalidate and Writeback) is maintained
by direct address indexing. See the previous paragraph for a definition of the direct address indexing
method. The operation to maintain consistency is an invalidate and writeback operation on the specified
Cache. If the operation is on the instruction Cache, then only the invalidation operation is performed, not the
writing back of the data in the Cache row. The data written back into which level of memory is determined
by the specific implementation of the Cache hierarchy and the inclusion or mutually exclusive relationship
between the levels. For data Cache or mixed Cache, it is up to the implementation to decide whether to
write back the data in the Cacche row only if it is dirty.
op[4:3]=2 means that Cache coherency is maintained by query indexing (Hit Invalidate / Invalidate and
Writeback).
The operation of maintaining Cache coherency here is the same as described in the above paragraph. The
so-called query index approach treats the VA of the CACOP instruction as a normal load instruction to
access the Cache to be operated on, and if it hits, it operates on the hit Cache row, otherwise it does not do
any operation. Since this query process may involve virtual-to-real address translation, the CACOP
instruction may trigger TLB-related exceptions in this case. However, since the CACOP instruction operates
on Cache rows, there is no need to consider address alignment or not in this case.
op[4:3]=3 is an implementation of a custom Cache operation and is not explicitly functionally defined in
the architecture specification.
4.2.4. TLB Maintenance Instructions
4.2.4.1. TLBSRCH
Instruction formats:
tlbsrch
The functional definition of the TLBSRCH instruction without implementing the LVZ extension is given here.
Use the information of CSR.ASID and CSR.TLBEHI to query TLB. If there is a hit entry, the index of the hit
entry is written to the Index field of CSR.TLBIDX, and the INV field of CSR.TLBIDX is set to 0; if there is
no hit entry, the INV field of CSR.TLBIDX is set to 1.
The rules for calculating the index of each entry in the TLB are, starting from 0, incremental numbering, first
STLB and then MTLB, STLB from the 0th line to the last line of the 0th way, then the 0th line to the last line
of the 1st way, until the last line of the last way, MTLB from the 0th line to the last line.
97
4.2.4.2. TLBRD
Instruction formats:
tlbrd
The functional definition of the TLBRD instruction without implementing the LVZ extension is given here.
The value of the Index field of CSR.TLBIDX is used as the index to read the specified entry in the TLB. If
the specified location is a valid TLB entry, the page table information of the TLB entry is written to
CSR.TLBEHI, CSR.TLBELO0, CSR.TLBELO1 and CSR.TLBIDX.PS, and the INV field of CSR.TLBIDX is
set to
0; if the specified location is an invalid TLB entry, then CSR.TLBEHI, CSR.TLBELO0 and
CSR.TLBELO1 is set to 0; and the INV field of CSR.TLBIDX is set to 1; TLBIDX.PS is set to 0 and the INV
field of CSR.TLBIDX is set to 1.
Note that valid/invalid TLB entries and valid/invalid page table entries in the TLB are two concepts.
If the index used for the access exceeds the range of the TLB, the behavior of the processor is undefinded.
4.2.4.3. TLBWR
Instruction formats:
tlbwr
The functional definition of the TLBWR instruction without implementing the LVZ extension is given here.
The TLBWR instruction fills the page table entry information stored in the TLB-related CSRs into the TLB.
The page table entry information to be populated comes from CSR.TLBEHI, CSR.TLBELO0,
CSR.TLBELO1 and CSR.TLBIDX_PS. If CSR.TLBIDX.NE=1, then the TLB is populated with an invalid TLB
entry; only if CSR.TLBIDX.NE=0, the TLB is populated with a valid TLB entry.
The location where the page table entry is written to the TLB is specified by the value of the Index field of
CSR.TLBIDX. Please refer to the TLBSRCH instruction for the calculation rules of each index in the TLB for
the specific corresponding rules. If a page table entry is to be written to the STLB, but a conflict occurs
between the value of the Index field of CSR.TLBIDX and VPPN and CSR.TLBIDX.PS in CSR.TLBEHI, the
behavior of the processor is undefinded.
4.2.4.4. TLBFILL
The functional definition of the TLBFILL instruction without implementing the LVZ extension is given here.
The TLBFILL instruction fills the page table entry information stored in the TLB-related CSRs into the TLB.
The page table entry information to be populated comes from CSR.TLBEHI, CSR.TLBELO0,
CSR.TLBELO1 and CSR.TLBIDX_PS. If CSR.TLBIDX.NE=1, then the TLB is populated with an invalid TLB
entry; only if CSR.TLBIDX.NE=0, the TLB is populated with a valid TLB entry.
Whether to write to STLB or MTLB is first made based on the page size of the page table entry being filled.
When the page size of the page table entry being filled is equal to the page size configured for STLB
(CSR.STLBPS) it will be filled to STLB, otherwise it will be filled to MTLB. Which way the page table entry is
filled to STLB, or which entry is filled to MTLB is randomly selected by the hardware.
98
4.2.4.5. TLBCLR
Instruction formats:
tlbclr
The contents of the TLB are invalidated according to the information of the TLB-related CSRs to maintain
the consistency of the page table data between the TLB and the memory. The functional definition of the
TLBCLR instruction without implementing the LVZ extension is given here.
When CSR.index.index falls within the range of MTLB (greater than or equal to the number of STLB
entries), TLBCLR is executed to invalidate all page table entries in MTLB with G=0 and ASID equal to
CSR.ASID.ASID.
When CSR.index.index falls within the STLB range (less than the number of STLB entries), execute a
TLBCLR to invalidate all page table entries in the STLB that are equal to G=0 and ASID equal to
CSR.ASID.ASID in the group indicated by the low bit of CSR.index.index.
4.2.4.6. TLBFLUSH
Instruction formats:
tlbflush
The contents of the TLB are invalidated according to the information of the TLB-related CSRs to maintain
the consistency of the page table data between the TLB and the memory. The functional definition of
TLBCLR instruction without implementing LVZ extension is given here.
When CSR.index.index falls within the MTLB range (greater than or equal to the number of STLB
entries), TLBCLR is executed to invalidate all page table entries in the MTLB.
When CSR.index.index falls within the STLB range (less than the number of STLB entries), a TLBCLR is
executed to invalidate all page table entries in the group indicated by the low CSR.index.index in the
STLB.
4.2.4.7. INVTLB
Instruction formats:
invtlb op, rj, rk
The INVTLB instruction is used to invalidate the contents of the TLB to maintain consistency of the page
table data between the TLB and memory. The functional definition of the INVTLB instruction is given here
for the case where the LVZ extension is not implemented.
Of the three source operands of the instruction, op is a 5-bit immediate number to indicate the type of
operation.
The [9:0] bits of the general register rj hold the ASID information required for the invalid operation
(called “register specified ASID”), and the remaining bits must be filled with 0. When the operation
99
indicated by op does not require an ASID, the general register rj should be set to r0.
The general register rk is used to store the virtual address information required for invalid operations
(called “register specified VA”). When the operation indicated by the op does not require virtual address
information, the general register rk should be set to r0.
The operations corresponding to each op are shown in the following table, and the op that does not appear
in the table will trigger a reserved instruction exception.
Table 13. Operations corresponding to each op in the INVTLB instruction
op
Operation
Clear all page table entries
0x0
0x1
Clears all page table entries. The effect of this operation is exactly the same as op=0.
0x2
Clears all G=1 page table entries.
0x3
Clears all page table entries with G=0.
0x4
Clears all page table entries with G=0 and ASID equal to the ASID specified in the register.
0x5
Clear all page table entries with G=0 and ASID equal to the register specified ASID, and VA
equal to the register specified VA.
0x6
Clear all page table entries where G=1 or ASID is equal to the ASID specified in the register
and VA is equal to the VA specified in the register.
4.2.5. Software page walking Instructions
4.2.5.1. LDDIR
Instruction formats:
lddir
rd, rj, level
The LDDIR instruction is used for accessing directory entries during software page table walking.
The 5-bit immediate level in the LDDIR instruction indicates which page table is currently being accessed.
level=1 corresponds to Dir0 in PWCL, level=2 corresponds to Dirl in PWCL, level=3 corresponds to
Dir2 in PWCH, and level=4 corresponds to Dir3 in PWCH.
If bit [6] of the general register rj is 0, it means that the content of rj is the physical address of the base
address of the level page table at this time. In this case, the LDDIR instruction will access the level page
table according to the current TLB refill address, retrieve the base address of the corresponding level+1
page table, and write it to the general register rd.
If bit [6] of general register rj is 1, it means that the content in rj is a large page (Huge Page) page table
entry. In this case, after executing the LDDRI instruction, the value in the general register rj will be written
directly to the general register rd.
4.2.5.2. LDPTE
Instruction formats:
100
ldpte
rj, seq
The LDPTE instruction is used for page table entry accesses during software page table walking.
The immediate number seq in the LDPTE instruction is used to indicate whether an even or odd number of
pages are being accessed. The result is written to CSR.TLBRELO0 when an even page is accessed. The
result will be written to CSR.TLBRELO1 when an odd page is accessed.
If bit [6] of the general register rj is 0, the content of rj is the physical address of the base address of
the page table at that level of the PTE. In this case, the LDPTE instruction will access the PTE level page
table according to the currently processed TLB refill address, retrieve the page table entry and write it to the
corresponding CSR.
If bit [6] of the general register rj is 1, it means that the content of rj is a large page (Huge Page) page
table entry. In this case, the LDPTE instruction is executed, and the value in general register rj is directly
converted into the final page table entry format and written to the corresponding CSR.
4.2.6. Other Miscellaneous Instructions
4.2.6.1. ERTN
Instruction formats:
ertn
The ERTN instruction is used to return from exception processing.
If the exception being processed is a debug exception clear the DM bit in the CSR.DEBUG to 0, and jump to
the address stored in the CSR.DEBUG to start fetching.
If the exception being processed is something other than a debug exception, update the PPLV, PIE, and
PWE information corresponding to the exception to CSR.CRMD, update the PVM in CSR.VMCTL to
CSR.VMCTL.VM, and jump to the ERA corresponding to the exception to start fetching instructions.
If the exception processed is an error-related exception, the PPLV, PIE and PWE information corresponding
to the exception is from CSR.MERRCTL, and the ERA corresponding to the exception is from
CSR.MERRERA. In addition, the PDA, PPG, PDCAF and PDCAM information in CSR.MERRCTL should be
updated to CSR.CRMD.
If the exception being processed is a TLB refill exception, the PPLV, PIE, and PWE information
corresponding to the exception is from CSR.TLBRPRMD, and the ERA corresponding to the exception is
from CSR.TLBRERA. In addition, it is necessary to clear DA field 0 and PG field 1 in CSR.CRMD.
If the exception being handled is not a debug exception, an error-related exception, or a TLB refill exception,
then the PPLV, PIE and PWE information corresponding to the exception is from CSR.PRMD, and the ERA
corresponding to the exception is from CSR.ERA.
When executing the ERTN instruction, if the KL0 bit in CSR.LLBCTL is not equal to 1, then the LLbit is set
to 0, otherwise the LLbit is not modified.
101
4.2.6.2. DBCL
Instruction formats:
dbcl
code
Executing DBCL instruction will immediately enter debug mode.
4.2.6.3. IDLE
Instruction formats:
idle
hint
After executing the IDLE instruction, the processor core will stop fetching instructions and enter the wait
state until it is woken up by an interrupt or is reset. After waking up from the wait state by an interrupt, the
first instruction executed by the processor core is the one after IDLE.
102
Chapter 5. Memory Management
5.1. Physical Address Space
The physical address space range of memory is 0-2PALEN-1.
In LA32, PALEN is theoretically a positive integer not exceeding 32, and its specific value is determined by
the implementation, which is usually recommended to be 32.
In LA64, PALEN is theoretically a positive integer not exceeding 60, and its specific value is determined by
the implementation.
The system software can determine the specific value of PALEN by reading the PALEN field of the 0x1
configuration word with the CPUCFG instruction.
5.2. Virtual Address Space and Address Translation Mode
The virtual address space is linear/flat in LoongArch. For PLV0 level, the virtual address space size is 232
bytes in LA32 and 264 bytes in LA64. However, the 264-byte virtual address space is not always legal in LA64.
It can be assumed that there are some virtual address holes. The legal virtual address space is closely
related to the address translation mode, which is described in the next section in conjunction with the
definition of the address translation mode.
The MMU in LoongArch supports two modes of translating virtual addresses to physical addresses: direct
address translation mode and mapped address translation mode.
When CSR.CRMD.DA=1 and CSR.CRMD.PG=0, the MMU of the processor core is in direct address
translation mode. In this mode, the physical address is by default equal to the [PALEN-1:0] bits of the
virtual address
(zero extension if necessary), unless the implementation uses other higher priority
translation rules. The entire virtual address space is legal at this point. The processor will enter the direct
address translation mode after reset.
When CSR.CRMD.DA=0 and CSR.CRMD.PG=1, the MMU of the processor core is in mapped address
translation mode. Specifically, there are two types of address translation modes: direct mapped address
translation mode (direct mapped mode) and page table mapped address translation mode (page table
mapped mode). When translating addresses, the direct mapped mode is preferred. Only when the address
cannot be translated by the direct mapped mode, the page table mapped mode is used for translation. See
Direct Mapped Address Translation Mode for details on the direct mapped mode and Memory
Management of Page Table Mapping for details on the page table mapped mode. The rules for virtual
address space legality during using the page table mapped mode in LA64 are presented here. The
[63:PALEN] bits of the legal virtual address must be the same as the [PALEN-1] bits, otherwise an
ADdress error Exception (ADE) will be triggered. In direct mapped mode, however, this address illegality
check is not required.
5.2.1. Direct Mapped Address Translation Mode
When the MMU of the processor core is in mapped address translation mode, direct mapping of virtual and
physical addresses can also be accomplished through the mechanism of direct mapping configuration
windows. There are four direct mapping configuration windows. The first two windows can be used for
both fetch and load/store operations, and the last two windows are used for load/store operations only.
The system software sets each of the four direct mapping configuration windows by configuring the
CSR.DMW0-CSR.DMW3 configuration window registers. Each window can be used to configure not only for
the address range, but also for the privilege levels under which the window is available, as well as the type
of memory access for virtual address within the address range.
103
In LA64, each direct mapping configuration window can be configured with a virtual address space which
length is PALEN bytes. When a virtual address hits a valid direct mapping configuration window, its
physical address is equal to the [PALEN-1:0] bits of itself. The hit is determined as follows: the highest 8
bits of the virtual address ([63:60] bits) are equal to the VSEG field in the configuration window register,
and the current privilege level is available.
For example, if PALEN is equal to 48 and DMWO is set to 0x9000000000000011, virtual address space
0x9000000000000000-0x9000FFFFFFFFFFFF will be directly mapped to physical address space 0x0-
0xFFFFFFFFFFFF at the PLV0 privilege level, the memory access type of which is consistent and
cacheable.
In LA32, each direct mapping configuration window can be configured with a virtual address space which
length is 229 bytes. When a virtual address hits a valid direct mapping configuration window, its physical
address is equal to the combination of the [28:0] bits of itself and the high bits of the the configuration
window register. The hit is determined as follows: the highest 4 bits of the virtual address ([31:29] bits)
are equal to the [31:29] bits in the configuration window register, and the current privilege level is
available.
For example, if DMW0 is set to 0x80000011, virtual address space 0x80000000-0x8FFFFFFF will be
directly mapped to physical address space 0x0-0x1FFFFFFF at the PLV0 privilege level, the memory
access type of which is consistent and cacheable.
5.2.2. 32-bit Address Mode in LA64
When the binary application in LA32 runs on the processor that implements LA64, the calculation involving
address in the instruction needs to be handled specially in order to obtain the same operation result, which
is the 32-bit address mode control in LA64. When VA32L1/VA32L2/VA32L3 in CSR.MISC is set to 1, the
software running at PLV1/PLV2/PLV3 level will run in 32-bit address mode. At this time, the virtual address
will be zero extended to 64 bits. The 32-bit results of executing instructions like BL, JIRL and PCADD will
also be sign extended to 64 bits.
5.2.3. Virtual Address Reduction Mode in LA64
In order to reduce the number of page table levels in some occasions, the virtual address reduction mode is
also provided in LA64. When the system software set RDVA in the CSR.RVACFG register to a value from 1
to 8, the valid bits of the virtual address in mapped address translation mode are treated as (VALEN-
RDVA) bits. For example, when VALEN=48 and RDVA is set to 8, the [63:40] bits of the legal address
must be a sign expansion of the [39] bit.
5.3. Memory Access Types
As mentioned in Memory Access Types, there are three types of memory access in LoongArch, including
CC, SUC, and WUC.
When the MMU of the processor core is in direct address translation mode, the memory access types of all
fetch operations are determined by CSR.CRMD.DATF, and the memory access types of all load/store
operations are determined by CSR.CRMD.DATM.
When the MMU of the processor core is in mapped address translation mode, the memory access types
are divided into two cases. If the address of a fetch or load/store operation falls on one of the direct
mapping configuration windows, then its memory access type is determined by the MAT field in the CSR
register that is configured in the window. If the fetch or load/store can only be mapped through the page
table, then its memory access type is determined by the MAT field in the page table entry.
104
In any case, the definition of the control value for the memory access type is always the same: 0 for
strongly-ordered uncached, 1 for coherent cached, 2 for weakly-ordered uncached, and 3 for reserved.
5.4. Memory Management of Page Table Mapping
In mapped address translation mode, all legal addresses, except those that fall in the direct mapping
configuration window, must be mapped through the page table to complete the translation of virtual
addresses to physical addresses. As a temporary Cache for the processor to store information about page
tables in the operating system, TLB is used to speed up the translation of virtual addresses to physical
addresses for fetch and load/store operations in mapped address translation mode.
5.4.1. TLB Organizational Structure
The TLB in LoongArch is divided into two parts, one is Singular-Page-Size TLB (STLB) which has the same
page size for all table entries, and the other is Multiple page size TLB (MTLB) which supports different page
sizes for different table entries.
The page size is the same as the page size configured in the STLB, and it is up to the implementation to
decide whether a page table entry can enter the MTLB, with no restrictions in the architecture specification.
During the translation of a virtual address to a physical address, the STLB and the MTLB look up
simultaneously. Accordingly, the software needs to ensure that there are no simultaneous hits of MTLB and
STLB, otherwise the processor behavior will be undefined.
The MTLBs are fully associative, and the STLBs are multi-way set associative. For STLB, if it has 2INDEX
groups and the configured page size is
2PS bytes, the hardware querying STLB is using the
[PS+INDEX:PS] bits of the virtual address as the index of each way.
5.4.2. TLB Entry
The table entry formats of STLB and MTLB is basically the same, the only difference is that each table entry
of MTLB contains the page size information, while STLB does not need to store the page size information
repeatedly because it is the same page size. For STLB, the page size of the page table entry is configured
by the system software in the PS field of the CSR.STLBPS register.
The format of each TLB table entry is shown in the figure and contains two parts: the comparison part and
the physical translation part.
Figure 6. TLB entry formats
The comparison part of TLB table entries includes:
•
Existence bit (E), 1 bit. When this bit is set, it indicates that the page table entry exists and can
participate in lookup matching.
•
Address Space IDentifier (ASID), 10 bits. ASID is used to distinguish the same virtual address in
different processes and to avoid performance loss caused by clearing the entire TLB during process
switching. The operating system assigns a unique ASID to each process, and the TLB needs to match
the ASID in addition to the address when performing lookups.
105
•
Global flag bit (G), 1 bit. When this bit is set, the lookup is not checked for ASID consistency. If the
operating system needs to share the same virtual address among all processes, this bit can be set.
•
Page Size (PS), 6 bits. PS appears only in the MTLB. It is used to specify the size of the pages stored in
this page table entry. The value is a power of 2 of the page size. That is, for a page size of 16KB,
PS=14.
•
Virtual Pair of Page frames Number (VPPN), (VALEN-13) bits. The physical translation part holds the
translation information for a adjacent odd even pair of page tables, so the virtual page number stored in
the TLB page table entry is the content of the virtual page number divided by 2 in the operating system.
The lowest bit of the virtual page number does not need to be stored. When searching for the TLB, the
lowest bit of the virtual page number is used to decide whether to select the odd-numbered page or the
even-numbered page for physical translation.
The physical translation part of the table entry holds the translation information for a adjacent odd even
pair of page tables, and the information for each page includes:
•
Valid bit (V), 1 bit. This bit is set when the page table entry is valid. Note the difference between the P
bit when performing lookups. The P bit refers to whether a page table entry on the TLB table entry is
present. A page table entry is present even if it is invalid (V=0).
•
Dirty bit (D), 1 bit. This bit is set when there is dirty data on the address space where the page table
entry is located.
•
Non-Readable bit (NR), 1 bit. This bit is set when no load operation is allowed on the address space
where this page table entry is located. This control bit is only exist in LA64.
•
Non-eXecutable bit (NX), 1 bit. This bit is set when a fetch operation is not allowed on the address
space where this page table entry is located. This control bit is only exist in LA64.
•
Memory Access Type (MAT), 2 bits. MAT controls the type of memory access that falls on the address
space where the page table entry is located. See Memory Access Types for the specific meaning of
each value.
•
Privilege LeVel (PLV), 2 bits. PLV refers to the privilege level corresponding to this page table entry.
When RPLV=0, the page table entry can be accessed by any program whose privilege level is not lower
than PLV; when RPLV=1, the page table entry can only be accessed by programs whose privilege level
is equal to PLV.
•
Restricted Privilege LeVel (RPLV), 1 bit. RPLV refers to whether a page table entry is accessed only by
programs corresponding to the privilege level. See above in PLV. This control bit is only exist in LA64.
•
Physical Page Number (PPN), (PALEN-12) bits. When the page size is larger than 4KB, the [log2PS-
1:12] bits of the PPN stored in the TLB can be any value.
5.4.3. Software Management of TLB
The management of TLBs in LoongArch involves software work. In the current version of this architecture
specification, TLB refill and consistent maintenance between TLB and page tables are still all led by
software.
5.4.3.1. TLB-related Exceptions
The TLB performs translation of virtual addresses to physical addresses automatically by hardware.
However, when there is no match in the TLB, or when the page table entry is invalid or illegally accessed
despite the match, an exception needs to be triggered and handed over to the OS kernel or other
supervisory programs. The exception is further handled by software to maintain the content of the TLB or
to make a final ruling on the legality of the program execution. The exceptions related to TLB management
in LoongArch are as follows:
106
•
TLB refill exception: This exception is triggered when the virtual address of an access operation does
not have a match in the TLB, which notifies the system software to perform a TLB refill. This exception
has a separate exception entry, a separate CSR for maintaining the exception context, and a separate
set of CSRs as TLB access interface; that means the exception is allowed to be triggered during the
processing of other exceptions. While the TLB refill exception being caught, CRMD will be set to 1 and
PG will be set to
0. This means the hardware will enter the direct address translation mode
automatically, so that the TLB refill exception handler itself will not trigger the TLB refill exception
again, and the exception context will not be saved and recovered. In order to distinguish CSRs used by
the TLB refill exception and CSRs available for other exceptions, the hardware will automatically set
CSR.TLBRERA.ISTLBR to 1 while the exception is caught.
•
Page invalid exception for load operation: This exception is triggered when the virtual address of the
load operation finds a match in the TLB with V=0.
•
Page invalid exception for store operation: This exception is triggered when the virtual address of the
store operation finds a match in the TLB with V=0.
•
Page invalid exception for fetch operation: This exception is triggered when the virtual address of the
fetch operation finds a match in the TLB with V=0.
•
Page privilege level ilegal exception: This exception is triggered when the virtual address of the access
operation finds a matching entry in the TLB with V=1, but the privilege level of the access is illegal. The
privilege level is illegal when RPLV=0 and CSR.CRMD.PLV is greater than the PLV in the page table
entry, or when RPLV=1 and CSR.CRMD.PLV is not equal to the PLV in the page table entry.
•
Page modify exception: This exception is triggered when the virtual address of the store operation finds
a match in the TLB with V=1 and privilege level is legal and D=0.
•
Page non-readable exception: This exception is triggered when the virtual address of the load operation
finds a match in the TLB with V=1 and privilege level is legal and NR=1.
•
Page non-executable exception: This exception is triggered when the virtual address of the fetch
operation finds a match in the TLB with V=1 and privilege level is legal and NX=1.
5.4.3.2. TLB-related Instructions
The TLB-related instructions mainly involve operations such as lookup, read, write, and invalidate the TLB
for filling, updating, and consistency maintenance of the TLB. See TLB Maintenance Instructions and
Software page walking Instructions for specific instruction definitions.
5.4.3.3. TLB-related CSRs
TLB-related CSRs are divided into three categories according to their functions. The first category is used
for the interactive interface of TLBs other than TLB refill exceptions. The second category is used for
software and hardware page walking. The third category is used for TLB refill exceptions.
The first category includes:
•
BADV
•
TLBEHI
•
TLBELO0
•
TLBELO1
•
TLBIDX
•
ASID
•
STLBPS
107
The second category includes:
•
PGDL
•
PGDH
•
PGD
•
PWCL
•
PWCH
The third category includes:
•
TLBRENTRY
•
TLBRERA
•
TLBRBADV
•
TLBREHI
•
TLBRELO0
•
TLBRELO1
•
TLBRPRMD
•
TLBRSAVE
See Basic Control and Status Registers for details of how each CSR register above interacts with the TLB.
5.4.3.4. Initialization of TLB
LoongArch allows not to implement the hardware initialization of the TLB, but to let the software in the boot
phase perform this function by executing INVTLB r0, r0.
5.4.4. TLB-based Translation of Virtual Addresses to Physical Addresses
The TLB-based translation of virtual addresses to physical addresses is described here. For the
convenience of description, the following is presented in pseudocode form with STLB first and MTLB
second, while the hardware implementation of the processor can look up STLB and MTLB at the same time.
# va: virtual address to be found.
# mem_type: memory acess type. FETCH refers to fetch operation, LOAD
refers to load operation, and STORE refers to store operation.
# plv: current privilege level, i.e., CSR.CRMD.PLV.
# pa: physical addresses after translation.
# mat: memory acess type after translation.
# VALEN: number of valid bits of the virtual address.
# PALEN: number of valid bits of the physical address.
# STLB[][]: STLB[N][M] refers to the Nth way and the Mth entry of STLB.
# STLB_WAY: number of ways of STLB.
# STLB_INDEX: the power of 2 of the number of groups in each way of
STLB, i.e., each way has 2STLB_INDEX groups.
# MTLB[]: MTLB[N] refers to the Nth entry of MTLB.
108
# MTLB_ENTRIES: number of entries of MTLB.
# look up STLB
stlb_found = 0
stlb_ps = CSR.STLBPS.PS
stlb_idx = va[stlb_ps+STLB_INDEX-1:stlb_ps]
for way in range(STLB_WAY):
if (STLB[way][stlb_idx].E == 1) and
((STLB[way][stlb_idx].G == 1) or (STLB[way][stlb_idx].ASID ==
CSR.ASID.ASID))
and
(STLB[way][stlb_idx].VPPN[VALEN-1:stlb_ps+1]==va[VALEN-
1:stlb_ps+1]):
if (stlb_found == 0):
stlb_found = 1
if (va[stlb_s] == 0):
sfound_v = STLB[way][stlb_idx].V0
sfound_d = STLB[way][stlb_idx].D0
sfoundnr = STLB[way][stlb_idx].NR0
sfound_ne = STLB[way][stlb_idx].NE0
sfound_mat = STLB[way][stlb_idx].MAT0
sfound_plv = STLB[way][stlb_idx].PLV0
sfound_rplv = STLB[way][stlb_idx].RPLV0
sfound_pfn = STLB[way][stlb_idx].PFN0
else:
sfound_v = STLB[way][stlb_idx].V1
sfound_d = STLB[way][stlb_idx].D1
sfound_nr = STLB[way][stlb_idx].NR1
sfound_ne = STLB[way][stlb_idx].NE1
sfound_mat = STLB[way][stlb_idx].MAT1
sfound_plv = STLB[way][stlb_idx].PLV1
sfound_rplv = STLB[way][stlb_idx].RPLV1
sfound_pfn = STLB[way][stlb_idx].PFN1
else:
# There are multiple hits, so the processor behavior will be
undefined.
# look up MTLB
mtlb_found = 0
for i in range (MTLB_ENTRIES):
if (MTLB[i].E == 1) and
((MTLB[i].G == 1) or (MTLB[i].ASID == CSR.ASID.ASID)) and
(MTLB[i].VPPN[VALEN-1:MTLB[i].PS+1] == va[VALEN-1:MTLB[i].PS+1]):
if (mtlb_found == 0):
109
mtlb_found = 1
mfound_ps - MTLB[i].PS
if (va[mfound_ps] == 0):
mfound_v = MTLB[i].V0
mfound_d = MTLB[i].DO
mfound_nr = MTLB[i].NRO
mfound_ne - MTLB[i].NEO
mfound_mat = MTLB[i].MATO
mfound_plv = MTLB[i].PLV0
mfound_rplv = MTLB[i].RPLVO
mfound_pfn = MTLB[i].PFNO
else:
mfound_v = MTLB[i].V1
mfound_d = MTLB[i].D1
mfound_nr = MTLB[i].NR1
mfound_ne = MTLB[i].NE1
mfound_mat = MTLB[i].MAT1
mfound_plv = MTLB[i].PLV1
mfound_rplv = MTLB[i].RPLV1
mfound_pfn = MTLB[i].PFN1
else:
# There are multiple hits, so the processor behavior will be
undefined.
if (stlb_found == 1) and (mtlb_found == 1):
# There are multiple hits, so the processor behavior will be
undefined.
elif (stlb_found == 1):
found_v = sfound_v
found_d = sfound_d
found_nr = sfound_nr
found_ne = sfound_ne
found_mat = sfound_mat
found_plv = sfound_plv
found_rplv = sfound_rplv
found_pfn = sfound_pfn
found_ps = stlb_ps
elif (mtlb_found == 1):
found_v = mfound_v
found_d = mfound_d
found_nr = mfound_nr
found_ne = mfound_ne
found_mat = mfound_mat
found_plv = mfound_plv
110
found_rplv = mfound_rplv
found_pfn = mfound_pfn
found_ps = mfound_ps
else:
SignalException(TLBRD)
# Trigger TLB refill exception.
if (found_v == 0):
case mem_type:
FETCH : SignalException(PIF)
# Trigger page invalid exception for
fetch operation.
LOAD : SignalException(PIL)
# Trigger page invalid exception for
load operation.
STORE : SignalException(PIS)
# Trigger page invalid exception for
store operation.
elif (mem_type == FETCH) and (found_ne == 1):
SignalException(PNX)
# Trigger page non-executable exception.
elif ((found_rplv == 0) and (plv > found_plv)) or
((found_rplv == 1) and (plv != found_plv)):
SignalException(PPE)
# Trigger page privilege level ilegal
exception.
elif (mem_type == L0AD) and (found_nr == 1):
SignalException(PNR)
# Trigger page non-readable exception.
elif (mem_type == STORE) and (found_d == 0)
and ((plv == 3) or (CSR.MISC[16+plv] == 0)) :
# The function
that disable the check of write protection is not enabled.
SignalException(PME)
# Trigger page modify exception.
else:
pa = {found_pfn[PALEN-1:found_ps], va[found.ps-1:0]}
mat = found_mat
5.4.5. Multi-level Page Table Structure Supported by page walking
Whether the LDDIR and LDPTE instructions are used to implement software page walking or hardware page
walking, the supported multi-level page table structure is the same, as shown in the figure.
111