Reference: <
Part B System Level Architecture
B1 System Level Programmers’ Model
B1.1 About the System level programmers’ model
B1.2 System level concepts and terminology
B1.2.1 Mode, state, and privilege level
Mode
The ARM architecture A and R profiles provide a set of modes that support normal software execution and handle
exceptions. The current mode determines:
• the set of registers that are available to the processor
• the privilege level of the executing software
State
- Instruction set state
one of ARM state, Thumb state, Jazelle state, or ThumbEE state.
- Execution state
consists of the instruction set state and some control bits that modify how the
instruction stream is decoded. For details, see Execution state registers on page A2-50 and Program
Status Registers (PSRs) on page B1-1147.
Security state
Debug state
Privilege level
Secure state
PL0 Software executed in User mode executes at PL0.
PL1 Software executed in any mode other than User mode executes at PL1.
Non-secure state
PL0 Software executed in User mode executes at PL0.
PL1 Software executed in any mode other than User or Hyp mode executes at PL1.
PL2 In an implementation that includes the Virtualization Extensions, software executed in
Hyp mode executes at PL2.
B1.3 ARM processor modes and ARM core registers
B1.3.1 ARM processor modes
Fixme [Table B1-1 ARM processor modes] page1139
System mode
Software executing in System mode executes at PL1. System mode has the same registers available
as User mode, and is not entered by any exception.
Supervisor mode
Supervisor mode is the default mode to which a Supervisor Call exception is taken.
Executing a SVC (Supervisor Call) instruction generates an Supervisor Call exception, that is taken
to Supervisor mode.
A processor enters Supervisor mode on Reset
Hyp mode
Hyp mode is the Non-secure PL2 mode, implemented as part of the Virtualization Extensions.
The Hypervisor Call exception and Hyp Trap exception are exceptions that are implemented as part
of the Virtualization Extensions, and that are always taken in Hyp mode.
• In Hyp mode, the only exception return is execution of an ERET instruction, see ERET on page B9-1982
• The instructions described in the following sections are UNDEFINED if executed in Hyp mode:
— SRS (Thumb) on page B9-2004
— SRS (ARM) on page B9-2006
— RFE on page B9-2000
— LDM (exception return) on page B9-1986
— LDM (User registers) on page B9-1988
— STM (User registers) on page B9-2008
— SUBS PC, LR and related instructions (ARM) on page B9-2012.
— SUBS PC, LR (Thumb) on page B9-2010, when executed with a nonzero constant.
• In Hyp mode, the CPACR has no effect on the execution of coprocessor, floating-point, or Advanced SIMD
instructions. The HCPTR controls execution of these instructions in Hyp mode.
• If software running in Hyp mode executes an SVC instruction, the Supervisor Call exception generated by the
instruction is taken to Hyp mode, see SVC (previously SWI) on page A8-720.
Monitor mode
Monitor mode is the mode to which a Secure Monitor Call exception is taken.
Monitor mode is a Secure mode, meaning it is always in the Secure state, regardless of the value of
the SCR.NS bit. Monitor mode provides the normal method of changing between the Secure and Non-secure security states.
Fixme [Figure B1-1 Modes, privilege levels, and security states] page1141
B1.3.2 ARM core registers
Fixme [Figure B1-2 ARM core registers, PSRs, and ELR_hyp, showing register banking] page1144
B1.3.3 Program Status Registers (PSRs)
The Current Program Status Register (CPSR)
The Current Program Status Register (CPSR) holds processor status and control information:
• the APSR, see The Application Program Status Register (APSR) on page A2-49
• the current instruction set state, see Instruction set state register, ISETSTATE on page A2-50
• the execution state bits for the Thumb If-Then instruction, see IT block state register, ITSTATE on page A2-51
• the current endianness, see Endianness mapping register, ENDIANSTATE on page A2-53
• the current processor mode
• interrupt and asynchronous abort disable bits.
The Saved Program Status Registers (SPSRs)
The purpose of an SPSR is to record the pre-exception value of the CPSR.
Fixme [Format of the CPSR and SPSRs] Page1148
B1.3.4 ELR_hyp
Hyp mode does not provide its own Banked copy of LR. Instead, on taking an exception to Hyp mode, the preferred
return address is stored in ELR_hyp, a 32-bit Special register implemented for this purpose.
ELR_hyp is implemented only as part of the Virtualization Extensions.
The ERET instruction uses the value in ELR_hyp as the return address for the exception. For more information, see
ERET on page B9-1982.
B1.4 Instruction set states
If an exception is taken to a PL1 mode, the SCTLR.TE bit for the security state the exception is taken to determines
the processor instruction set state that handles the exception, and if necessary, the processor changes to this
instruction set state on exception entry.
If the exception is taken to Hyp mode, the HSCTLR.TE bit determines the processor instruction set state that
handles the exception, and if necessary, the processor changes to this instruction set state on exception entry.
B1.5 The Security Extensions
B1.5.1 Security states
The Security Extensions define two security states, Secure state and Non-secure state.
• Each security state operates in its own virtual memory address space, with its own translation regime.
— in any implementation that includes the Security Extensions, Monitor mode is available only in Secure
state
— in an implementation that also includes the Virtualization Extensions, Hyp mode is available only in
Non-secure state.
The ARM core registers and the processor status registers are not Banked between the Secure and the Non-secure
states. ARM expects that, when switching execution between the Non-secure and Secure states, a kernel running
mostly in Monitor mode will switch the values of these registers.
The registers LR_mon and SPSR_mon are UNKNOWN when executing in Non-secure state.
Changing from Secure to Non-secure state
Except in Monitor mode and Hyp mode, the security state is controlled by the SCR.NS bit. Software executing in a Secure PL1 mode can change the SCR, but ARM strongly recommends that software obeys the following rules for changing SCR.NS:
• To avoid security holes, software must not:
— Change from Secure to Non-secure state by using an MSR or CPS instruction to switch from Monitor
mode to some other mode while SCR.NS is 1.
— Use an MCR instruction that writes SCR.NS to change from Secure to Non-secure state. This means
ARM recommends that software does not alter SCR.NS in any mode except Monitor mode. ARM
deprecates changing SCR.NS in any other mode.
• The usual mechanism for changing from Secure to Non-secure state is an exception return.To return to
Non-secure state, software executing in Monitor mode sets SCR.NS to 1 and then performs the exception
return.
B1.6 The Large Physical Address Extension
The Large Physical Address Extension is an OPTIONAL extension to the ARMv7-A architecture profile. Any
implementation that includes the Large Physical Address Extension must also include the Multiprocessing
Extensions.
The Large Physical Address Extension adds a new translation table format:
• the format used in an implementation that does not include the Large Physical Address Extension is now
called the Short-descriptor format, see Short-descriptor translation table format on page B3-1324
• the format added by the Large Physical Address Extension is the Long-descriptor format, see
Long-descriptor translation table format on page B3-1338.
An implementation that includes the Large Physical Address Extension must support both translation table formats.
B1.7 The Virtualization Extensions
The Virtualization Extensions are an OPTIONAL extension to the ARMv7-A architecture profile. Any
implementation that includes the Virtualization Extensions must include the Security Extensions, the Large Physical
Address Extension, and the Multiprocessing Extensions.
The basic model of a virtualized system involves:
• a hypervisor, running in Non-secure Hyp mode, that is responsible for switching Guest operating systems
• a number of Guest operating systems, each of which runs in the Non-secure PL1 and PL0 modes
• for each Guest operating system, applications, that usually run in User mode.
Each virtual machine is identified by a virtual machine identifier (VMID), assigned by the hypervisor.
• With the Security Extensions, the Virtualization Extensions control the routing of interrupts and
asynchronous Data Abort exceptions to the appropriate one of:
— the current Guest OS
— a Guest OS that is not currently running
— the hypervisor
— the Secure monitor.
• When an implementation includes the Virtualization Extensions, it provides independent translation regimes
for memory accesses from:
— Secure modes, the Secure PL1&0 translation regime
— Non-secure Hyp mode, the Non-secure PL2 translation regime
— Non-secure PL1 and PL0 modes, the Non-secure PL1&0 translation regime
• In the Non-secure PL1&0 translation regime, address translation occurs in two stages:
— Stage 1 maps the Virtual Address (VA) to an Intermediate Physical Address (IPA). Typically, the Guest
OS configures and controls this stage, and believes that the IPA is the Physical Address (PA)
— Stage 2 maps the IPA to the PA. Typically, the hypervisor controls this stage, and a Guest OS is
completely unaware of this translation.
B1.7.1 Impact of the Virtualization Extensions on the modes and exception model
• Implements new exceptions, see:
— Hypervisor Call (HVC) exception on page B1-1212
— Hyp Trap exception on page B1-1209
— Virtual IRQ exception on page B1-1221
— Virtual FIQ exception on page B1-1223
— Virtual Abort exception on page B1-1218.
• Implements a new register that holds the exception vector base address for exceptions taken to Hyp mode,
the HVBAR.
• Implements a new exception return instruction, ERET, for return from Hyp mode
• Provide mechanisms to trap processor functions to Hyp mode, using the Hyp Trap exception, see Traps to
the hypervisor on page B1-1248.
When an operation is trapped to Hyp mode, the hypervisor typically either:
— emulates the required operation, so the application running in the Guest OS is unaware of the trap to
Hyp mode
— returns an error to the Guest OS.
B1.8 Exception handling
B1.8.1 Exception vectors and the exception base address
When an exception is taken, processor execution is forced to an address that corresponds to the type of exception.
This address is called the exception vector for that exception.
A set of exception vectors comprises eight consecutive word-aligned memory addresses, starting at an exception
base address. These eight vectors form a vector table. For the IRQ and FIQ exceptions only, when the exceptions
are taken to IRQ mode and FIQ mode, software can change the exception vectors from the vector table values by
setting the SCTLR.VE bit to 1, see Vectored interrupt support on page B1-1168.
Implementation that does not include the Security Extensions (1 pair interrupt vectors)
This section applied to all ARMv7-R implementations.
An implementation that does not include the Security Extensions has a single vector table, the base
address of which is selected by SCTLR.V, see SCTLR, System Control Register, VMSA on
page B4-1707 or SCTLR, System Control Register, PMSA on page B6-1932:
V == 0 Exception base address = 0x00000000. This setting is referred to as normal vectors, or as
low vectors.
V == 1 Exception base address = 0xFFFF0000. This setting is referred to as high vectors, or
Hivecs.
Implementation that includes the Security Extensions (3 pair interrupt vectors)
Any implementation that includes the Security Extensions has the following vector tables:
• One for exceptions taken to Secure Monitor mode. This is the Monitor vector table, and is in
the address space of the Secure PL1&0 translation regime.
• One for exceptions taken to Secure PL1 modes other than Monitor mode. This is the Secure
vector table, and is in the address space of the Secure PL1&0 translation regime.
• One for exceptions taken to Non-secure PL1 modes. This is the Non-secure vector table, and
is in the address space of the Non-secure PL1&0 translation regime.
For the Monitor vector table, MVBAR holds the exception base address.
For the Secure vector table:
• the Secure SCTLR.V bit determines the exception base address:
V == 0 The Secure VBAR holds the exception base address.
V == 1 Exception base address = 0xFFFF0000, the Hivecs setting.
For the Non-secure vector table:
• the Non-secure SCTLR.V bit determines the exception base address:
V == 0 The Non-secure VBAR holds the exception base address.
V == 1 Exception base address = 0xFFFF0000, the Hivecs setting.
Implementation that includes the Virtualization Extensions (4 pair interrupt vectors)
An implementation that includes the Virtualization Extensions must include the Security
Extensions, and also includes an additional vector table. Therefore, it has the following vector
tables:
• One for exceptions taken to Secure Monitor mode. This is the Monitor vector table, and is in
the address space of the Secure PL1&0 translation regime.
• One for exceptions taken to Secure PL1 modes other than Monitor mode. This is the Secure
vector table, and is in the address space of the Secure PL1&0 translation regime.
• One for exceptions taken to Hyp mode, the Non-secure PL2 mode. This is the Hyp vector
table, and is in the address space of the Non-secure PL2 translation regime.
• One for exceptions taken to Non-secure PL1 modes. This is the Non-secure vector table, and
is in the address space of the Non-secure PL1&0 translation regime.
The exception base addresses of the Monitor vector table, the Secure vector table, and the
Non-secure vector table are determined in the same way as for an implementation that includes the
Security extensions but not the Virtualization extensions.
For the Hyp vector table, HVBAR holds the exception base address.
The vector tables and exception offsets
Fixme [Table B1-3 The vector tables] page1167
B1.8.4 Processor mode for taking exceptions
Exceptions taken to Hyp mode
• Any exception taken from Hyp mode, that is not routed to Secure Monitor Mode by the controls described
in Asynchronous exception routing controls on page B1-1175, is taken to Hyp mode.
• The following exceptions, if taken from Non-secure state, are taken to Hyp mode:
— An abort that Routing of aborts on page B3-1396 identifies as taken to Hyp mode.
— A Hyp Trap exception, see Traps to the hypervisor on page B1-1248.
— A Hypervisor Call exception. This is generated by executing a HVC instruction in a Non-secure mode.
— An asynchronous abort, IRQ exception or FIQ exception that is not routed to Secure Monitor mode
but is explicitly routed to Hyp mode, as described in Asynchronous exception routing controls on
page B1-1175.
— A synchronous external abort, Alignment fault, Undefined Instruction exception, or Supervisor Call
exception taken from the Non-secure PL0 mode and explicitly routed to Hyp mode, as described in
Routing general exceptions to Hyp mode on page B1-1192.
Note
A synchronous external abort can be routed to Hyp mode only if it not routed to Secure Monitor mode.
— A debug exception that is explicitly routed to Hyp mode as described in Routing Debug exceptions to
Hyp mode on page B1-1194.
Asynchronous exception routing controls
In an implementation that includes the Security Extensions, the following bits in the SCR control the routing of
asynchronous exceptions:
SCR.EA When this bit is set to 1, any external abort is taken to Secure Monitor mode
SCR.FIQ When this bit is set to 1, any FIQ exception is taken to Secure Monitor mode.
SCR.IRQ When this bit is set to 1, any IRQ exception is taken to Secure Monitor mode.
Only Secure software can change the values of these bits.
In an implementation that includes the Virtualization Extensions, the following bits in the HCR route asynchronous
exceptions to Hyp mode:
HCR.AMO If SCR.EA is set to 0, when this bit is set to 1, an asynchronous external abort taken from a
Non-secure PL1 or PL0 mode is taken to Hyp mode, instead of to Non-secure Abort mode.
HCR.FMO If SCR.FIQ is set to 0, when this bit is set to 1, an FIQ exception taken from a Non-secure PL1 or
PL0 mode is taken to Hyp mode, instead of to Non-secure FIQ mode.
HCR.IMO If SCR.IRQ is set to 0, when this bit is set to 1, an IRQ exceptions taken from a Non-secure PL1 or
PL0 mode is taken to Hyp mode, instead of to Non-secure IRQ mode.
Only software executing in Hyp mode, or Secure software executing in Monitor mode when SCR.NS is set to 1, can change the values of these bits.
B1.8.5 Processor state on exception entry
Instruction set state on exception entry
On exception entry, CPSR.{T, J} are set to the values shown, with the CPSR.T value determined by SCTLR.TE or HSCTLR.TE
Fixme [Table B1-8 CPSR.J and CPSR.T bit values on exception entry] page1182
CPSR.E bit value on exception entr
Fixme [Table B1-9 CPSR.E bit value on exception entry] page1182
B1.8.6 Asynchronous exception masking
The CPSR.{A, I, F} bits can mask the corresponding exceptions, as follows:
• CPSR.A can mask asynchronous aborts
• CPSR.I can mask IRQ exceptions
• CPSR.F can mask FIQ exceptions.
In an ARMv7 implementation that does not include the Security Extensions, setting one of these bits to 1 masks the
corresponding exception, meaning the exception cannot be taken.
In an implementation that includes the Security Extensions, the SCR.{AW, FW} bits provide a mechanism to
prevent use of the CPSR.{A, F} mask bits by Non-secure software. In an implementation that includes the
Virtualization Extensions:
• HCR.{AMO, FMO} modify this mechanism
• HCR.IMO can prevent the masking, by CPSR.I, of IRQs taken from Non-secure state.
When an SCR.{AW, FW} bit is set to 0, Non-secure software cannot update the corresponding
CPSR bit.
Fixme [Table B1-11 Control of masking by CPSR.A] page1185
Fixme [Table B1-12 Control of masking by CPSR.I] page1185
Fixme [Table B1-13 Control of masking by CPSR.F] page1185
B1.8.7 Summaries of asynchronous exception behavior
Asynchronous exception behavior, Security Extensions only
Fixme [Table B1-14 Behavior of asynchronous aborts, Virtualization Extensions not implemented] page1187
Fixme [Table B1-15 Behavior of IRQ exceptions, Virtualization Extensions not implemented] page1188
Fixme [Table B1-16 Behavior of FIQ exceptions, Virtualization Extensions not implemented] page1188
Asynchronous exception behavior, with the Virtualization Extensions
Fixme [Table B1-17 Behavior of asynchronous aborts, Virtualization Extensions implemented] page1189
Fixme [Table B1-18 Behavior of IRQ exceptions, Virtualization Extensions implemented] page1190
Fixme [Table B1-19 Behavior of FIQ exceptions, Virtualization Extensions implemented] page1191
B1.8.8 Routing general exceptions to Hyp mode
When HCR.TGE is set to 1, and the processor is in Non-secure User mode, the following exceptions are taken to
Hyp mode, instead of to the default Non-secure mode for handling the exception:
• Undefined Instruction exceptions.
• Supervisor Call exceptions.
• Synchronous External aborts.
• Any Alignment fault other than an alignment fault caused by the memory type when SCTLR.M is 1.
B1.8.9 Routing Debug exceptions to Hyp mode
When HDCR.TDE is set to 1, if the processor is executing in a Non-secure mode other than Hyp mode, any Debug
exception is routed to Hyp mode. This means it generates a Hyp Trap exception
B1.8.10 Exception return
On an exception return, the CPSR takes either:
• the value loaded by the RFE instruction
• if the exception return is not performed by executing an RFE instruction, the value of the current SPSR at the
time of the exception return
Return from an exception taken to a PL1 mode
For an exception taken to a PL1 mode, the ARM architecture provides the following exception return instructions:
• Data-processing instructions with the S bit set and the PC as a destination, see SUBS PC, LR (Thumb) on
page B9-2010 and SUBS PC, LR and related instructions (ARM) on page B9-2012.
Typically:
— a return where no subtraction is required uses SUBS with an operand of 0, or the equivalent MOVS
instruction
— a return requiring subtraction uses SUBS with a nonzero operand.
• From ARMv6, the RFE instruction, see RFE on page B9-2000. If a subtraction is required, typically it is
performed before saving the LR value to memory.
• In ARM state, a form of the LDM instruction, see LDM (exception return) on page B9-1986. If a subtraction is
required, typically it is performed before saving the LR value to memory.
Return from an exception taken to a PL2 mode
For an exception taken to a PL2 mode, the ARM architecture provides the ERET instruction, see ERET on
page B9-1982. An exception handler executing in a PL2 mode must return using the ERET instruction.
Hyp mode is the only PL2 mode. Both Hyp mode and the ERET instruction are implemented only as part of the
Virtualization Extensions.
B1.8.11 Virtual exceptions in the Virtualization Extensions
Fixme [Table B1-20 HCR bits controlling asynchronous exceptions] page1198
B1.8.12 Low interrupt latency configuration
Setting SCTLR.FI to 1 enables the low interrupt latency configuration of an implementation. This configuration can
reduce the interrupt latency of the processor. The mechanisms implemented to achieve low interrupt latency are
IMPLEMENTATION DEFINED. For the description of the SCTLR see either:
• SCTLR, System Control Register, VMSA on page B4-1707
• SCTLR, System Control Register, PMSA on page B6-1932
B1.8.13 Wait For Event and Send Event
ARMv7 and ARMv6K provide a mechanism, the Wait For Event mechanism, that permits a processor in a
multiprocessor system to request entry to a low-power state, and, if the request succeeds, to remain in that state until
it receives an event generated by a Send Event operation on another processor in the system.
example using for spin-lock
The Virtualization Extensions provide a bit that traps to Hyp mode any attempt to enter a low-power state from a
Non-secure PL1 or PL0 mode.
WFE wake-up events
The following events are WFE wake-up events:
• the execution of an SEV instruction on any processor in the multiprocessor system
• a physical IRQ interrupt, unless masked by the CPSR.I bit
• a physical FIQ interrupt, unless masked by the CPSR.F bit
• a physical asynchronous abort, unless masked by the CPSR.A bit
• in Non-secure state in any mode other than Hyp mode:
— when HCR.IMO is set to 1, a virtual IRQ interrupt, unless masked by the CPSR.I bit
— when HCR.FMO is set to 1, a virtual FIQ interrupt, unless masked by the CPSR.F bit
— when HCR.AMO is set to 1, a virtual asynchronous abort, unless masked by the CPSR.A bit
• an asynchronous debug event, if invasive debug is enabled and the debug event is permitted
• an event sent by the timer event stream, see Event streams on page B8-1964
• an event sent by some IMPLEMENTATION DEFINED mechanism.
The Event Register
The Event Register is a single bit register for each processor. When set, an event register indicates that an event has
occurred, since the register was last cleared
The Event Register is set by:
• an SEV instruction
• an event sent by some IMPLEMENTATION DEFINED mechanism
• a debug event that causes entry into Debug state
• an exception return.
The Send Event instruction
The Send Event instruction, SEV, causes an event to be signaled to all processors in the multiprocessor system.
ARM recommends that software includes a DSB instruction before an SEV instruction
Execution of the Send Event instruction sets the Event Register. The Send Event instruction is available at all privilege levels
The Wait For Event instruction
The action of the Wait For Event instruction depends on the state of the Event Register:
• If the Event Register is set, the instruction clears the register and completes immediately. Normally, if this
happens the software makes another attempt to claim the lock.
• If the Event Register is clear the processor can suspend execution and enter a low-power state. It can remain
in that state until the processor detects a WFE wake-up event or a reset. When the processor detects a WFE
wake-up event, or earlier if the implementation chooses, the WFE instruction completes.
The Wait For Event instruction, WFE, is available at all privilege levels,
B1.8.14 Wait For Interrupt
When a processor issues a WFI instruction it can suspend execution and enter a low-power state.
The Virtualization Extensions provide a bit that traps to Hyp mode any attempt to enter a low-power state from a
Non-secure PL1 or PL0 mode.
The processor can remain in the WFI low-power state until it is reset, or it detects one of the following WFI wake-up
events:
• a physical IRQ interrupt, regardless of the value of the CPSR.I bit
• a physical FIQ interrupt, regardless of the value of the CPSR.F bit
• a physical asynchronous abort, regardless of the value of the CPSR.A bit
• in Non-secure state in any mode other than Hyp mode:
— when HCR.IMO is set to 1, a virtual IRQ interrupt, regardless of the value of the CPSR.I bit
— when HCR.FMO is set to 1, a virtual FIQ interrupt, regardless of the value of the CPSR.F bit
— when HCR.AMO is set to 1, a virtual asynchronous abort, regardless of the value of the CPSR.A bit
• an asynchronous debug event, when invasive debug is enabled and the debug event is permitted.
WFI wake-up events cannot be masked by the mask bits in the CPSR.
Using WFI to indicate an idle state on bus interfaces
Linux cpuidle framework(1)_概述和软件架构
B1.9 Exception descriptions
skip
B1.10 Coprocessors and system control
The ARM architecture supports sixteen coprocessors, usually referred to as CP0 to CP15.
The architecture reserves two of these coprocessors, CP14 and CP15,
for configuration and control related to the architecture:
• CP14 is reserved for the configuration and control of:
— debug features, see The CP14 debug register interface on page C6-2123
— trace features, see the Embedded Trace Macrocell Architecture Specification and the CoreSight
Program Flow Trace Architecture Specification
— the Thumb Execution Environment, see Thumb Execution Environment on page B1-1240
— direct Java bytecode execution, see Jazelle direct bytecode execution on page B1-1241.
• CP15 is called the System Control coprocessor, and is reserved for the control and configuration of the ARM
processor system, including architecture and feature identification.
The implementation of the CP15 registers depends heavily on whether the ARMv7 implementation is:
• an ARMv7-A implementation with a Virtual Memory System Architecture (VMSA)
• an ARMv7-R implementation with a Protected Memory System Architecture (PMSA).
The implementation of the CP14 registers is generally similar in ARMv7-A and ARMv7-R implementation.
Most CP14 and CP15 registers are accessible only from PL1 or higher. For possible accesses from PL0:
• The register descriptions in Chapter B4 System Control Registers in a VMSA implementation and Chapter B6
System Control Registers in a PMSA implementation indicate whether a register is accessible from PL0.
• The descriptions of the CP14 interface in Chapter C6 Debug Register Interfaces include the permitted
accesses to the debug registers from PL0.
• The following sections summarize the permitted accesses to CP15 registers from PL0:
— for a VMSA implementation, PL0 views of the CP15 registers on page B3-1488
— for a PMSA implementation, PL0 views of the CP15 registers on page B5-1797.
B1.11 Advanced SIMD and floating-point support
skip
B1.12 Thumb Execution Environment
skip
B1.13 Jazelle direct bytecode execution
skip
B1.14 Traps to the hypervisor
B1.14.1 General information about traps to the hypervisor
The Hyp Trap exception provides the standard mechanism for trapping Guest OS functions to the hypervisor.
and enters the exception handler using the vector at
offset 0x14 from the Hyp vector base address. For more information see Exception handling on page B1-1165
A Hyp Trap exception can be generated only when all of the following apply:
• The processor is both:
— not in Debug state
— in a Non-secure PL1 or PL0 mode.
• Traps to Hyp mode never apply in Secure state, regardless of the value of the SCR.NS bit.
B1.14.2 Trapping ID mechanisms
For a small number of frequently-accessed ID registers, the Virtualization Extensions provide read/write aliases of
the registers, accessible only from Hyp mode, or from Secure state. A read of the original ID register from a
Non-secure PL1 mode actually returns the value of the read/write alias register.
Fixme [Table B1-26 ID register substitution by the Virtualization Extensions] page1251
Fixme [Table B1-27 ID register groups for Hyp Trap exceptions] page1252
B1.14.17 Summary of trap controls
Fixme [Table B1-29 Summary of Hyp trap controls] page1262
B2 Common Memory System Architecture Features
B2.2 Caches and branch predictors
B2.2.1 Cache identification
The ARMv7 cache identification consists of a set of registers that describe the implemented caches that are under
the control of the processor:
• A single Cache Type Register defines:
— the minimum line length of any of the instruction caches
— the minimum line length of any of the data or unified caches
— the cache indexing and tagging policy of the Level 1 instruction cache.
For more information, see:
— CTR, Cache Type Register, VMSA on page B4-1556, for a VMSA implementation
— CTR, Cache Type Register, PMSA on page B6-1835, for a PMSA implementation.
• A single Cache Level ID Register defines:
— the type of cache implemented at a each cache level, up to the maximum of seven levels
— the Level of Coherence (LoC) for the caches
— the Level of Unification (LoU) for the caches.
For more information, see:
— CLIDR, Cache Level ID Register, VMSA on page B4-1530, for a VMSA implementation
— CLIDR, Cache Level ID Register, PMSA on page B6-1816, for a PMSA implementation
• A single Cache Size Selection Register selects the cache level and cache type of the current Cache Size
Identification Register, see:
— CSSELR, Cache Size Selection Register, VMSA on page B4-1555, for a VMSA implementation
— CSSELR, Cache Size Selection Register, PMSA on page B6-1834, for a PMSA implementation.
• For each implemented cache, across all the levels of caching, a Cache Size Identification Register defines:
— whether the cache supports Write-Through, Write-Back, Read-Allocate and Write-Allocate
— the number of sets, associativity and line length of the cache
For more information, see:
— CCSIDR, Cache Size ID Registers, VMSA on page B4-1528, for a VMSA implementation
— CCSIDR, Cache Size ID Registers, PMSA on page B6-1814, for a PMSA implementation.
Identifying the cache resources in ARMv7
In ARMv7 the architecture defines support for multiple levels of cache, up to a maximum of seven levels.
software must:
Read the Cache Type Register to find the indexing and tagging policy used for the Level 1 instruction cache.
This register also provides the size of the smallest cache lines used for the instruction caches, and for the data
and unified caches. These values are used in cache maintenance operations.Read the Cache Level ID Register to find what caches are implemented. The register includes seven Cache
type fields, for cache levels 1 to 7. Scanning these fields, starting from Level 1, identifies the instruction, data
or unified caches implemented at each level. This scan ends when it reaches a level at which no caches are
defined. The Cache Level ID Register also provides the Level of Unification (LoU) and the Level of
Coherence (LoC) for the cache implementation.For each cache identified at stage 2:
• Write to the Cache Size Selection Register to select the required cache. A cache is identified by its
level, and whether it is:
— an instruction cache
— a data or unified cache.
• Read the Cache Size ID Register to find details of the cache.
B2.2.2 Cache behavior
General behavior of the caches
When a memory location is marked with a Normal Cacheable memory attribute, determining whether a copy of the
memory location is held in a cache still depends on many aspects of the implementation. The following
non-exhaustive list of factors might be involved:
• the size, line length, and associativity of the cache
• the cache allocation algorithm
• activity by other elements of the system that can access the memory
• speculative instruction fetching algorithms
• speculative data fetching algorithms
• interrupt behaviors.
For the purpose of these principles, a cache entry covers at least 16 bytes and no more than 2KB of contiguous
address space, aligned to its size.
Behavior of the caches at reset
In ARMv7:
• All caches are disabled at reset.
• An implementation can require the use of a specific cache initialization routine to invalidate its storage array
before it is enabled.
B2.2.3 Cache enabling and disabling
Levels of cache on page B2-1265 indicates that:
• In ARMv7 the architecture defines the control of multiple levels of cache.
• Before ARMv7 the architecture defines the control of only one level of cache.
In ARMv7:
• SCTLR.C enables or disables all data and unified caches for data accesses, across all levels of cache visible
to the processor. It is IMPLEMENTATION DEFINED whether it also enables or disables the use of unified caches
for instruction accesses.
• SCTLR.I enables or disables all instruction caches, across all levels of cache visible to the processor.
- SCTLR, System Control Register, VMSA on page B4-1707, for a VMSA implementation
- SCTLR, System Control Register, PMSA on page B6-1932, for a PMSA implementation.
B2.2.4 Branch predictors
Branch predictor hardware typically uses a form of cache to hold branch information. The ARM architecture
permits this branch predictor hardware to be visible to software, and so the branch predictor is not architecturally
invisible. This means that under some circumstances software must perform branch predictor maintenance to avoid
incorrect execution caused by out-of-date entries in the branch predictor.
Requirements for branch predictor maintenance operations
the instructions at the virtual addresses change:
• enabling or disabling the MMU
• writing new mappings to the translation tables
• any change to the TTBR0, TTBR1, or TTBCR registers, unless accompanied by a change to the ContextID,
or a change to the VMID
• changes to the VTTBR or VTCR registers, unless accompanied by a change to the VMID.
then branch predictor maintenance operations must be performed to invalidate entries in the branch
predictor, to ensure that the change is visible to subsequent execution.
B2.2.6 About ARMv7 cache and branch predictor maintenance functionality
Terms used in describing the maintenance operations
• by the address of the memory location to be maintained, referred to as operating by MVA
• by a mechanism that describes the location in the hardware of the cache, referred to as operating by set/way.
Terminology for operations by MVA
The term Modified Virtual Address (MVA) relates to the Fast Context Switch Extension (FCSE) mechanism,described in Appendix D10 Fast Context Switch Extension (FCSE). When the FCSE is absent or disabled, the MVA and VA have the same value.
Virtual addresses only exist in systems with a MMU. When no MMU is implemented, or all applicable MMUs are disabled, the MVA and VA are identical to the PA.
Terminology for operations by set/way
Cache maintenance operations by set/way refer to the particular structures in a cache.
Level
The cache level of the hierarchy.
Set
Each level of a cache is split up into a number of sets. Each set is a set of locations in a cache level to which an address can be assigned.
Way
The Associativity of a cache defines the number of locations in a set to which an address can be assigned.
B2.2.7 Cache and branch predictor maintenance operations
Cache and branch predictor maintenance operations are performed using accesses to CP15 c7. The following
sections define the encodings for these operations:
• Cache and branch predictor maintenance operations, VMSA on page B4-1743, for a VMSA implementation
• Cache and branch predictor maintenance operations, PMSA on page B6-1943, for a PMSA implementation.
Summary of cache and branch predictor maintenance operations
Data cache and unified cache operations
Operations by MVA
The data and unified cache operations by MVA are:
DCIMVAC Invalidate, to point of coherency.
DCCMVAC Clean, to point of coherency.
DCCMVAU Clean, to point of unification.
DCCIMVAC Clean and invalidate, to point of coherency.
Operations by set/way
The data and unified cache operations by set/way are:
DCISW Invalidate.
DCCSW Clean.
DCCISW Clean and invalidate, to point of coherency.
Instruction cache operations
Operation by MVA
ICIMVAU Invalidate, to point of unification.
Operations on all entries
The instruction cache operations that operate on all entries are:
ICIALLU Invalidate all, to point of unification.
ICIALLUIS Invalidate all, to point of unification, Inner Shareable.
Branch predictor operations
Operation by MVA
BPIMVA Invalidate.
Operations on all entries
BPIALL Invalidate all.
BPIALLIS Invalidate all, Inner Shareable.
B3 Virtual Memory System Architecture (VMSA)
B3.1 About the VMSA
In VMSAv7, a Memory Management Unit (MMU) controls address translation, access permissions, and memory
attribute determination and checking.
Each supported stage of memory system control is provided by an MMU, with its own independent set of controls.
Therefore, the Extended VMSAv7 provides the following MMUs:
• Secure PL1&0 stage 1 MMU
• Non-secure PL2 stage 1 MMU
• Non-secure PL1&0 stage 1 MMU
• Non-secure PL1&0 stage 2 MMU.
Fixme [Figure B3-1 VMSA translation regimes, and associated MMUs]page1309
B3.1.1 Address types used in a VMSA description
Virtual Address (VA)
An address used in an instruction, as a data or instruction address, is a Virtual Address (VA).
An address held in the PC, LR, or SP, is a VA.
Modified Virtual Address (MVA)
On an implementation that implements and uses the FCSE(Appendix D10 Fast Context Switch Extension (FCSE)), the FCSE takes a VA and transforms it to an MVA.
Intermediate Physical Address (IPA)
In a translation regime that provides two stages of address translation, the IPA is the address after
the stage 1 translation, and is the input address for the stage 2 translation.
Physical Address (PA)
B3.1.2 Address spaces in a VMSA implementation
The ARMv7 architecture supports:
• A VA address space of up to 32 bits. The actual width is IMPLEMENTATION DEFINED.
• An IPA address space of up to 40 bits. The translation tables and associated system control registers define the width of the implemented address space.
Note:
The Large Physical Address Extension defines two translation table formats. The Long-descriptor format gives access to the full 40-bit IPA or PA address space at a granularity of 4KB. The Short-descriptor format:
• Gives access to a 32-bit PA address space at 4KB granularity.
• Optionally, gives access to a 40-bit PA address space, but only at 16MB granularity.
If an implementation includes the Security Extensions, the address maps are defined independently for Secure and Non-secure operation, providing two independent 40-bit address spaces, where:
• a VA accessed from Non-secure state can only be translated to the Non-secure address map
• a VA accessed from Secure state can be translated to either the Secure or the Non-secure address map.
B3.1.3 About address translation
B3.1.3.1. VMSAv7 without the Security Extensions
Supports only a single PL1&0 stage 1 MMU. Operation of this MMU can be split between two sets of translation tables, defined by TTBR0 and TTBR1, and controlled by TTBCR.
B3.1.3.2. VMSAv7 with the Security Extensions but without the Virtualization Extensions
Supports only the Secure PL1&0 stage 1 MMU and the Non-secure PL1&0 stage 1 MMU.
Operation of each of these MMUs can be split between two sets of translation tables, defined by the Secure and Non-secure copies of TTBR0 and TTBR1, and controlled by the Secure and Non-secure copies of TTBCR.
Note: Secure and Non-secure has copies of TTBR0 and TTBR1, TTBCR.
B3.1.3.3. VMSAv7 with Virtualization Extensions
Secure PL1&0 stage 1 MMU
Operation of this MMU can be split between two sets of translation tables, defined by the Secure copies of TTBR0 and TTBR1, and controlled by the Secure copy of TTBCR.
Non-secure PL2 stage 1 MMU
The HTTBR defines the translation table for this MMU, controlled by HTCR.
Non-secure PL1&0 stage 1 MMU
Operation of this MMU can be split between two sets of translation tables, defined by the Non-secure copies of TTBR0 and TTBR1 and controlled by the Non-secure copy of TTBCR.
Non-secure PL1&0 stage 2 control
The VTTBR defines the translation table for this MMU, controlled by VTCR.
Fixme [Figure B3-2 Memory translation summary, with Virtualization Extensions]Page 1312
A full translation table lookup is called a translation table walk.It is performed automatically by hardware.
Translation Lookaside Buffers (TLBs) reduce the average cost of a memory access by caching the results of translation table walks.
To reduce the software overhead of TLB maintenance, the VMSA distinguishes between Global pages and Process-specific pages. The Address Space Identifier (ASID) identifies pages associated with a specific process and provides a mechanism for changing process-specific tables without having to maintain the TLB tructures.
If an implementation includes the Virtualization Extensions, the virtual machine identifier (VMID) identifies the current virtual machine, with its own independent ASID space.
B3.2 The effects of disabling MMUs on VMSA behavior
About the VMSA on page B3-1308 defines the translation regimes and the associated MMUs. The VMSA includes
an enable bit for each MMU, as follows:
• SCTLR.M, in the Secure copy of the register, controls Secure PL1&0 stage 1 MMU
• SCTLR.M, in the Non-secure copy of the register, controls Non-secure PL1&0 stage 1 MMU
• HCR.VM controls Non-secure PL1&0 stage 2 MMU
• HSCTLR.M controls Non-secure PL2 stage 1 MMU.
B3.2.1 VMSA behavior when a stage 1 MMU is disabled
Non-secure PL1 and PL0 accesses when HCR.DC is set to 1, Virtualization Extensions
In an implementation that includes the Virtualization Extensions, for an access from a Non-secure PL1 or PL0 mode when HCR.DC is set to 1, the stage 1 translation assigns the Normal Non-shareable, Inner Write-Back Write-Allocate, Outer Write-Back Write-Allocate memory attributes.
All other accesses
Data access
The stage 1 translation assigns the Strongly-Ordered memory type.
Note
This means the access is Non-cacheable. Unexpected data cache hit behavior is IMPLEMENTATION DEFINED.
Instruction access
The stage 1 translation assigns Normal memory attribute, with the cacheability and
shareability attributes determined by the value of:
• the Secure copy of SCTLR.I for the Secure PL1&0 translation regime
• the Non-secure copy of SCTLR.I for the Non-secure PL1&0 translation regime
• HSCTLR.I for the Non-secure PL2 translation regime.
B3.2.2 VMSA behavior when the stage 2 MMU is disabled
When the stage 2 MMU is disabled:
• the IPA output from the stage 1 translation maps flat to the PA
• the memory attributes and permissions from the stage 1 translation apply to the PA.
If the stage 1 MMU and the stage 2 MMU are both disabled, see Behavior of instruction fetches when all associated
MMUs are disabled.
B3.3 Translation tables
VMSAv7 defines two alternative translation table formats:
Short-descriptor format
This is the original format defined in issue A of this Architecture Reference Manual, and is the only format supported on implementations that do not include the Large Physical Address Extension. It uses 32-bit descriptor entries in the translation tables, and provides:
• Up to two levels of address lookup.
• 32-bit input addresses.
• Output addresses of up to 40 bits.
• Support for PAs of more than 32 bits by use of supersections, with 16MB granularity.
• Support for No access, Client, and Manager domains.
• 32-bit table entries.
Long-descriptor format
The Large Physical Address Extension adds support for this format. It uses 64-bit descriptor entries in the translation tables, and provides:
• Up to three levels of address lookup.
• Input addresses of up to 40 bits, when used for stage 2 translations.
• Output addresses of up to 40 bits.
• 4KB assignment granularity across the entire PA range.
• No support for domains, all memory regions are treated as in a Client domain.
• 64-bit table entries.
• Fixed 4KB table size, unless truncated by the size of the input address space.
The Large Physical Address Extension is an OPTIONAL extension, but an implementation that includes the Virtualization Extensions must also include the Large Physical Address Extension.
B3.3.1 Translation table walks
A translation table walk occurs as the result of a TLB miss, and starts with a read of the appropriate starting-level
translation table.
The physical address of the base of the starting-level translation table is determined from the appropriate Translation
table base register (TTBR).
B3.3.2 Information returned by a translation table lookup
If the required translation table descriptor is not held in a TLB, a translation table walk is performed to obtain the descriptor. A lookup, whether from the TLB or as the result of a translation table walk, returns both:
• an output address that corresponds to the input address for the lookup
• a set of properties that correspond to that output address.
The returned properties are classified as providing address map control, access controls, or region attributes.
B3.3.3 Determining the translation table base address
Fixme[Figure B3-2 Memory translation summary, with Virtualization Extensions]page1312
B3.3.4 Security Extensions control of translation table walks
When an implementation includes the Security Extensions, two bits in the TTBCR for the current security state
control whether a translation table walk is performed on a TLB miss. These two bits are the:
• PD0 and PD1 bits, on a processor using the Short-descriptor translation table format
• EPD0 and EPD1 bits, on a processor using the Long-descriptor translation table format.
The effect of these bits is:
{E}PDx == 0 If a TLB miss occurs based on TTBRx, a translation table walk is performed. The current security
state determines whether the memory access is Secure or Non-secure.
{E}PDx == 1 If a TLB miss occurs based on TTBRx, a First level Translation fault is returned, and no translation
table walk is performed.
B3.3.5 Access to the Secure or Non-secure physical address map
As stated in Address spaces in a VMSA implementation on page B3-1311, a processor that implements the Security
Extensions implements independent Secure and Non-secure address maps. These are defined by the translation
tables identified by the Secure TTBR0 and TTBR1. In both translation table formats:
• In the Secure translation tables, the NS bit in a descriptor indicates whether the descriptor refers to the Secure
or the Non-secure address map:
NS == 0 Access the Secure physical address space.
NS == 1 Access the Non-secure physical address space.
B3.5 Short-descriptor translation table format
The Short-descriptor translation table format supports a memory map based on memory sections or pages:
Supersections
Consist of 16MB blocks of memory. Support for Supersections is optional, except that an
implementation that includes the Large Physical Address Extension and supports more that 32 bits
of Physical Address must also support Supersections to provide access to the entire Physical
Address space.
Sections
Consist of 1MB blocks of memory.
Large pages
Consist of 64KB blocks of memory.
Small pages
Consist of 4KB blocks of memory.
When using the Short-descriptor translation table format, two levels of translation tables are held in memory:
- First-level table
- Second-level tables
In the translation tables, in general, a descriptor is one of:
• an invalid or fault entry
• a page table entry, that points to a next-level translation table
• a page or section entry, that defines the memory properties for the access
• a reserved format.
Bits[1:0] of the descriptor give the primary indication of the descriptor type.
Fixme[Figure B3-3 General view of address translation using Short-descriptor format translation tables] Page 1325
B3.5.1 Short-descriptor translation table format descriptors
Short-descriptor translation table first-level descriptor formats
Fixme [Figure B3-4 Short-descriptor first-level descriptor formats] Page1326
Descriptor bits[1:0] identify the descriptor type.
Short-descriptor translation table second-level descriptor formats
Fixme [Figure B3-5 Short-descriptor second-level descriptor formats] Page1327
B3.5.2 Memory attributes in the Short-descriptor translation table format descriptors
TEX[2:0], C, B
Memory region attribute bits, see Memory region attributes on page B3-1366.
These bits are not present in a Page table entry
XN bit
The Execute-never bit. Determines whether the processor can execute software from the addressed
region, see Execute-never restrictions on instruction fetching on page B3-1359.
This bit is not present in a Page table entry.
PXN bit, when supported
The Privileged execute-never bit:
• On an implementation that does not include the Large Physical Address Extension, support
for the PXN bit in the Short-descriptor translation table format is OPTIONAL.
• On an implementation that includes the Large Physical Address Extension, the
Short-descriptor translation table format must include the PXN bit.
NS bit
Non-secure bit. If an implementation includes the Security Extensions, for memory accesses from
Secure state, this bit specifies whether the translated PA is in the Secure or Non-secure address map
Domain
Domain field, see Domains, Short-descriptor format only on page B3-1362.
Page table descriptor applies to all entries in the corresponding second-level translation table.
AP[2], AP[1:0]
Access Permissions bits, see Memory access control on page B3-1356
S bit
The Shareable bit.
nG bit
The not global bit. Determines how the translation is marked in the TLB, see Global and
process-specific translation table entries on page B3-1378.
B3.5.4 Selecting between TTBR0 and TTBR1, Short-descriptor translation table format
the value of TTBCR.N indicates the number of most significant bits of the input VA that determine whether TTBR0 or TTBR1 :
• If N == 0 then use TTBR0. Setting TTBCR.N to zero disables use of a second set of translation tables.
• if N > 0 then:
— if bits[31:32-N] of the input VA are all zero then use TTBR0
— otherwise use TTBR1.
Fixme [Table B3-1 Effect of TTBCR.N on address translation, Short-descriptor format] page1330
Whenever TTBCR.N is nonzero, the size of the translation table addressed by TTBR1 is 16KB.
Fixme [Figure B3-6 How TTBCR.N controls the boundary between the TTBRs, Short-descriptor format] page1331
B3.5.5 Translation table walks, when using the Short-descriptor translation table format
Reading a first-level translation table
Fixme [Figure B3-7 Accessing first-level translation table based on TTBR0, Short-descriptor format] page1332
The full translation flow for Sections, Supersections, Small pages and Large pages
Fixme [Figure B3-11 Small page address translation] page1337
B3.6 Long-descriptor translation table format
Fixme [Figure B3-12 General view of stage 1 address translation using Long-descriptor format]page1338
B3.6.1 Long-descriptor translation table format descriptors
In general, a descriptor is one of:
• an invalid or fault entry
• a table entry, that points to the next-level translation table
• a block entry, that defines the memory properties for the access
• a reserved format.
Long-descriptor translation table first-level and second-level descriptor formats
Fixme [Figure B3-14 Long-descriptor first-level and second-level descriptor formats]page1340
Long-descriptor translation table third-level descriptor formats
Fixme [Figure B3-15 Long-descriptor third-level descriptor formats]page1341
B3.6.3 Control of Secure or Non-secure memory access, Long-descriptor format
In the Long-descriptor format:
• the NS bit relates only to the memory block or page at the output address defined by the descriptor
• the descriptors also include an NSTable bit, see Hierarchical control of Secure or Non-secure memory
accesses, Long-descriptor format.
NSTable == 0 The defined table address is in the Secure physical address space.
NSTable == 1 The defined table address is in the Non-secure physical address space.
B3.6.4 Selecting between TTBR0 and TTBR1, Long-descriptor translation table format
The TTBCR.T0SZ and TTBCR.T1SZ size fields control the use of TTBR0 and TTBR1,
Fixme [Table B3-2 Use of TTBR0 and TTBR1, Long-descriptor format]page1345
Fixme [Figure B3-18 Control of TTBR boundary, when TTBCR.T1SZ is zero]page1346
B3.6.5 Long-descriptor translation table format address lookup levels
Fixme [Table B3-3 Properties of the three levels of address lookup with Long-descriptor translation tables]page1348
B3.6.6 Translation table walks, when using the Long-descriptor translation table format
Example Full translation flow, starting at second-level lookup
Fixme [Figure B3-22 Complete Long-descriptor format stage 1 translation, starting at second level]page1355
B3.7 Memory access control
In addition to an output address, a translation table entry that refers to page or region of memory includes fields that
define properties of the target memory region.
B3.7.1 Access permissions
Access permission bits in a translation table descriptor control access to the corresponding memory region. The
Short-descriptor translation table format supports two options for defining the access permissions:
• three bits, AP[2:0], define the access permissions
• two bits, AP[2:1], define the access permissions, and AP[0] can be used as an Access flag.
SCTLR.AFE selects the access permissions option. Setting this bit to 1, to enable the Access flag, also selects use
of AP[2:1] to define access permissions
The Long-descriptor translation table format uses only AP[2:1] to control the access permissions, and provides an
AF bit for use as an Access flag
AP[2:1] access permissions model
Fixme [Table B3-6 VMSAv7 AP[2:1] access permissions model]page1357
AP[2:0] access permissions control, Short-descriptor format only
Fixme [Table B3-8 VMSAv7 MMU access permissions]page1358
B3.7.2 Execute-never restrictions on instruction fetching
Execute-never (XN) controls provide an additional level of control on memory accesses permitted by the access
permissions settings.
XN, Execute-never
When the XN bit is 1, a Permission fault is generated if the processor attempts to execute an
instruction fetched from the corresponding memory region.
PXN, Privileged execute-never
When the PXN bit is 1, a Permission fault is generated if the processor is executing at PL1 and
attempts to execute an instruction fetched from the corresponding memory region.
B3.7.3 Domains, Short-descriptor format only
A domain is a collection of memory regions. The Short-descriptor translation table format supports 16 domains, and
requires the software that defines a translation table to assign each VMSA memory region to a domain.
B3.7.4 The Access flag
The Access flag indicates when a page or section of memory is accessed for the first time since the Access flag in
the corresponding translation table descriptor was set to 0
B3.7.5 PL2 control of Non-secure access permissions
Non-secure software executing at PL2 controls two sets of translation tables, both of which use the Long-descriptor
translation table format:
• The translation tables that control the Non-secure PL2 stage 1 translations. These map VAs to PAs, for
memory accesses made when executing in Non-secure state at PL2, and are indicated and controlled by the
HTTBR and HTCR.
The HAP[2:1] field in the stage 2 descriptors define the stage 2 access permissions
Fixme [Table B3-9 Stage 2 control of access permissions]page1365
B3.8 Memory region attributes
B3.8.1 Overview of memory region attributes for stage 1 translations
Memory type and attributes
These are described either:
• Directly, by bits in the translation table descriptor.
• Indirectly, by registers referenced by bits in the table descriptor. This is described as
remapping the memory type and attribute description.
The Short-descriptor translation table format can use either of these approaches, selected by the
SCTLR.TRE bit:
TRE == 0 Remap disabled. The TEX[2:0], C, and B bits in the translation table descriptor define
the memory region attributes.
TRE == 1 Remap enabled. The TEX[0], C, and B bits in the translation table descriptor are index
bits to the MMU remap registers, that define the memory region attributes:
• the Primary Region Remap Register, PRRR
• the Normal Memory Remap Register, NMRR
The Long-descriptor translation table format always uses remapping.
Shareability
In the Short-descriptor translation table format, the S bit in the translation table descriptor encodes
whether the region is shareable.
B3.8.2 Short-descriptor format memory region attributes, without TEX remap
Fixme [Table B3-10 TEX, C, and B encodings when TRE == 0]page1367
Cacheable memory attributes, without TEX remap
When TEX[2] == 1, the translation table entry describes Cacheable memory, and the rest of the encoding defines
the Inner and Outer cache attributes:
TEX[1:0] Define the Outer cache attribute.
C, B Define the Inner cache attribute.
Fixme [Table B3-11 Inner and Outer cache attribute encoding]page1368
B3.8.3 Short-descriptor format memory region attributes, with TEX remap
• The software that defines the translation tables must program the PRRR and NMRR to define seven possible
memory region attributes.
• The TEX[0], C, and B bits of the translation table descriptors define the memory region attributes, by
indexing PRRR and NMRR.
Fixme [Table B3-12 TEX, C, and B encodings when TRE == 1]page1369
B3.8.4 Long-descriptor format memory region attributes
the AttrIndx[2:0] field in a block or page translation table descriptor for a stage 1 translation indicates the 8-bit field in the appropriate MAIR, that specifies
the attributes for the corresponding memory region:
• AttrIndx[2] indicates the value of n in MAIRn:
AttrIndx[2] == 0 Use MAIR0.
AttrIndx[2] == 1 Use MAIR1
• AttrIndx[2:0] indicates the required Attr field, Attrn, where n = AttrIndx[2:0].
Each AttrIndx field defines, for the corresponding memory region:
• The memory type, Strongly-ordered, Device, or Normal.
• For Normal memory
— the inner and outer cacheability, Non-cacheable, Write-Through, or Write-Back
— for Write-Through Cacheable and Write-Back Cacheable regions, the Read-Allocate and
Write-Allocate policy hints, each of which is Allocate or Do not allocate
Shareability, Long-descriptor format
Fixme [Table B3-14 SH[1:0] field encoding for Normal memory, Long-descriptor format]page1373
For a Device or Strongly-ordered memory region, the value of the SH[1:0] field of the translation table descriptor
is ignored.
B3.9 Translation Lookaside Buffers (TLBs)
Translation Lookaside Buffers (TLBs) are an implementation technique that caches translations or translation table entries.
TLBs avoid the requirement for every memory access to perform a translation table walk in memory.
B3.9.1 Global and process-specific translation table entries
In a VMSA implementation, system software can divide a virtual memory map used by memory accesses at PL1 and PL0 into global and non-global regions, indicated by the nG bit in the translation table descriptors:
nG == 0
The translation is global, meaning the region is available for all processes.
nG == 1
The translation is non-global, or process-specific, meaning it relates to the current ASID, as defined by the CONTEXTIDR.
B3.9.2 TLB matching
B3.9.3 TLB behavior at reset
The ARMv7 architecture does not require a reset to invalidate the TLB. All TLBs are disabled from reset. All MMUs are disabled from reset, and the contents of the TLBs have no effect on address translation.
B3.9.5 TLB conflict aborts
The Large Physical Address Extension introduces the concept of a TLB conflict abort, and adds fault status encodings for such an abort.
An implementation can generate a TLB conflict abort if it detects that the address being looked up in the TLB hits multiple entries.
In some implementations, multiple hits in the TLB can generate a synchronous Data Abort or Prefetch Abort exception.
B3.10 TLB maintenance requirements
B3.10.1 General TLB maintenance requirements
The architecture defines CP15 c8 functions for TLB maintenance operations, and supports the following operations:
- invalidate all unlocked entries in the TLB
- invalidate a single TLB entry, by MVA, or MVA and ASID for a non-global entry
- invalidate all TLB entries that match a specified ASID.
The Multiprocessing Extensions add the following operations:
• invalidate all TLB entries that match a specified MVA, regardless of the ASID
Using break-before-make when updating translation table entries
ARM strongly recommends the use of a break-before-make when changing translation table entries whenever multiple threads of execution can use the same translation tables and the change to the translation entries involves any of:
• A change of the memory type.
• A change of the cacheability attributes.
• A change of the output address (OA), if the OA of at least one of the old translation table entry and the new
translation table entry is writable.
break-before-make
- Replace the old translation table entry, and execute DSB instruction.
- Invalidate the translation table entry with a broadcast TLB invalidation instruction, and execute a DSB instruction
- Write the new translation table entry, and execute a DSB instruction
B3.10.2 Maintenance requirements on changing system control register values
The TLB contents can be influenced by control bits in a number of system control registers.
The system control register changes that this applies to are:
• any change to the NMRR, PRRR, MAIRn, or HMAIRn registers
• any change to the SCTLR.AFE bit, see Changing the Access flag enable
• any change to the SCTLR.TRE bit
• any change to the translation table base address in TTBR0
• any change to the translation table base address in TTBR1
• in an implementation that includes the Virtualization Extensions:
— any change to the SCTLR.{WXN, UWXN} bits
— any change to the SCR.SIF bit
— any change to the HCR.VM bit
— any change to HCR.PTW bit, see Changing HCR.PTW
— any change to the HTTBR.BADDR field
— any change to the VTTBR.BADDR field
• in an implementation that includes the Large Physical Address Extension, changing TTBCR.EAE, see
Changing the current Translation table format on page B3-1386
• when using the Short-descriptor translation table format:
— any change to the RGN, IRGN, S, or NOS fields in TTBR0 or TTBR1
— any change to the PD0 or PD1 fields in TTBCR
• when using the Long-descriptor translation table format:
— any change to the TnSZ, ORGNn, IRGNn, SHn, or EPDn fields in the TTBCR, where n is 0 or 1
— any change to the T0SZ, ORGN0, IRGN0, or SH0 fields in the HTCR
— any change to the T0SZ, ORGN0, IRGN0, or SH0 fields in the VTCR.
B3.10.3 Atomicity of register changes on changing virtual machine
From the viewpoint of software executing in a Non-secure PL1 or PL0 mode, when there is a switch from one virtual
machine to another, the registers that control or affect address translation must be changed atomically.
This applies to the registers for:
• Non-secure PL1&0 stage 1 address translations. This means that all of the following registers must change atomically:
— PRRR and NMRR, if using the Short-descriptor translation table format
— MAIR0 and MAIR1, if using the Long-descriptor translation table format
— TTBR0, TTBR1, TTBCR, DACR, and CONTEXTIDR
— the SCTLR.
These registers apply to execution in Non-secure PL1&0 modes. However, when updated as part of a switch of virtual machines they are updated by software executing in Hyp mode.
• Non-secure PL1&0 stage 2 address translations. This means that all of the following registers and register
fields must change atomically:
— VTTBR and VTCR
— HMAIR0 and HMAIR1
— the HSCTLR.
B3.11 Caches in a VMSA implementation
B3.11.1 Data and unified caches
The behavior of accesses from the same observer to different VAs, that are translated to the same PA with the same memory attributes, is fully coherent. This means these accesses behave as follows, regardless of
which VA is accessed:
• two writes to the same PA occur in program order
• a read of a PA returns the value of the last successful write to that PA
• a write to a PA that occurs, in program order, after a read of that PA, has no effect on the value returned by
that read.
The memory system behaves in this way without any requirement to use barrier or cache maintenance operations.
B3.11.2 Instruction caches
In the ARM architecture, an instruction cache is a cache that is accessed only as a result of an instruction fetch.
Therefore, an instruction cache is never written to by any load or store instruction executed by the processor.
The ARMv7 architecture supports three different behaviors for instruction caches:
• Physically-indexed, physically-tagged(PIPT) instruction caches
• Virtually-indexed, physically-tagged (VIPT) instruction caches
• ASID and VMID tagged Virtually-indexed, virtually-tagged (VIVT) instruction caches.
B3.11.2.1 PIPT instruction caches & VIPT instruction caches
For PIPT instruction caches, the use of memory address translation is entirely transparent to all instruction fetches
that are not UNPREDICTABLE.
An implementation that provides PIPT/VIPT instruction caches implements the IVIPT extension, see IVIPT architecture
extension
B3.11.2.2 IVIPT architecture extension
It reduces the instruction cache maintenance requirement to the following condition:
• instruction cache maintenance is required only after writing new data to a physical address that holds an
instruction.
B3.11.2.3 ASID and VMID tagged VIVT instruction caches
Instruction maintenance can also be required as a result of any of the following situations:
• enabling or disabling the MMU
• writing new mappings to the translation tables
• any change to the TTBR0, TTBR1, or TTBCR registers, unless accompanied by a change to the ContextID,
or a change to the VMID
• changes to the VTTBR or VTCR registers, unless accompanied by a change to the VMID
B3.12 VMSA memory aborts
In a VMSAv7 implementation, the following mechanisms cause a processor to take an exception on a failed memory
access:
Debug exception
An exception caused by the debug configuration, see About debug exceptions on
page C4-2090.
Alignment fault
An Alignment fault is generated if the address used for a memory access does not have the
required alignment for the operation. For more information see Unaligned data access on
page A3-108 and Alignment faults on page B3-1402.
MMU fault
An MMU fault is a fault generated by the fault checking sequence for the current translation
regime.
External abort
Any memory system fault other than a Debug exception, an Alignment fault, or an MMU
fault
B3.12.1 Routing of aborts
A memory abort is either a Data Abort exception or a Prefetch Abort exception. The mode to which a memory abort
is taken depends on the reason for the exception, the mode the processor is in when it takes the exception:
Memory aborts taken to Monitor mode
If an implementation includes the Security Extensions, when SCR.EA is set to 1, all External aborts
are taken to Monitor mode. This applies to aborts taken from Secure modes and from Non-secure
modes.
Memory aborts taken to Secure Abort mode
If an implementation includes the Security Extensions, when the processor is executing in Secure
state, all memory aborts that are not routed to Monitor mode are taken to Secure Abort mode.
Memory aborts taken to Hyp mode
大致都发生在Hyp mode，Non-secure 时至少也是在stage 2 发生的错误（stage 1 VA -> IPA; stage2 IPA-> PA. 虚拟地址->中间地址->物理地址）
includes the Virtualization Extensions, the processor is executing in Non-secure state
• Alignment faults taken:
— When the processor is in Hyp mode.
— When the processor is in a PL1 or PL0 mode and the exception is generated because
the Non-secure PL1&0 stage 2 translation identifies the target of an unaligned access
as Device or Strongly-ordered memory.
— When the processor is in the PL0 mode and HCR.TGE is set to 1. For more
information see Synchronous external abort, when HCR.TGE is set to 1 on
page B1-1193.
• When the processor is using the Non-secure PL1&0 translation regime:
— MMU faults from stage 2 translations, for which the stage 1 translation did not cause
an MMU fault.
— Any abort taken during the stage 2 translation of an address accessed in a stage 1
translation table walk that is not routed to Secure Monitor mode
• When the processor is using the Non-secure PL2 translation regime, MMU faults from
stage 1 translations.
• External aborts, if SCR.EA is set to 0 and any of the following applies:
— The processor was executing in Hyp mode when it took the exception.
— The processor was executing in a Non-secure PL0 or PL1 mode when it took the
exception, the abort is asynchronous, and HCR.AMO is set to 1.
— The processor was executing in the Non-secure PL0 mode when it took the exception,
the abort is synchronous, and HCR.TGE is set to 1. For more information see
Synchronous external abort, when HCR.TGE is set to 1 on page B1-1193.
— The abort occurred on a stage 2 translation table walk.
• Debug exceptions, if HDCR.TDE is set to 1.
Memory aborts taken to Non-secure Abort mode
In an implementation that does not include the Security Extensions, all memory aborts are taken to
Abort mode.
Otherwise, when the processor is executing in Non-secure state, the following aborts are taken to
Non-secure Abort mode:
• When the processor is in a Non-secure PL1 or PL0 mode, Alignment faults taken for any of
the following reasons:
— SCTLR.A is set to 1.
— An instruction that does not support unaligned accesses is committed for execution,
and the instruction accesses an unaligned address.
— The implementation includes the Virtualization Extensions, and the PL1&0 stage 1
translation identifies the target of an unaligned access as Device or Strongly-ordered
memory.
• When the processor is using the Non-secure PL1&0 translation regime, MMU faults from
stage 1 translations.
• External aborts, if all of the following apply:
— the abort is not on a stage 2 translation table walk
— the processor is not in Hyp mode
— SCR.EA is set to 0
— the abort is asynchronous, and HCR.AMO is set to 0
— the abort is synchronous, and HCR.TGE is set to 0• When the processor is using the Non-secure PL1&0 translation regime, MMU faults from
stage 1 translations.
• External aborts, if all of the following apply:
— the abort is not on a stage 2 translation table walk
— the processor is not in Hyp mode
— SCR.EA is set to 0
— the abort is asynchronous, and HCR.AMO is set to 0
— the abort is synchronous, and HCR.TGE is set to 0
B3.12.3 The MMU fault-checking sequence
In a VMSA implementation, all memory accesses require VA to PA translation. Therefore, when a corresponding
MMU is enabled, each access requires a lookup of the translation table descriptor for the accessed VA.
When using the Short-descriptor format
• There are one or two levels of lookup.
• Lookup always starts at the first level.
• The final level of lookup checks the Domain field of the descriptor and:
— faults if there is no access to the Domain
— checks the access permissions only for Client domains.
When using the Long-descriptor format
• There are one, two, or three levels of lookup.
• Lookup starts at either the first level or the second level.
• Domains are not supported. All accesses are treated as Client domain accesses.
Fixme [Figure B3-23 Fetching the descriptor in a translation table walk]Page1400
Fixme [Figure B3-24 VMSA fault checking sequence]Page1401
Stage 2 fault on a stage 1 translation table walk, Virtualization Extensions
When an implementation that includes the Virtualization Extensions is operating in a Non-secure PL1 or PL0 mode,
any memory access goes through two stages of translation:
• stage 1, from VA to IPA
• stage 2, from IPA to PA
B3.12.4 Alignment faults
The ARMv7 memory architecture requires support for strict alignment checking. This checking is controlled by
SCTLR.A.
An Alignment fault can occur on an access for which the MMU is disabled.
In an implementation that includes the Virtualization Extensions, any unaligned access to memory region with the Device or Strongly-ordered memory type attribute generates an Alignment fault.
B3.12.5 MMU faults
This section describes the faults that might be detected during one of the fault-checking sequences described in The
MMU fault-checking sequence.
The following subsections describe the MMU faults that might be detected during a fault checking sequence:
• External abort on a translation table walk
• Translation fault
• Access flag fault on page B3-1404
• Domain fault, Short-descriptor format translation tables only on page B3-1404
• Permission fault on page B3-1405.
Translation fault
A Translation fault can be generated at any level of lookup, and the reported fault code identifies the lookup level.
A Translation fault is generated if bits[1:0] of a translation table descriptor identify the descriptor as either a Fault
encoding or a reserved encoding.
In addition, if an implementation includes the Virtualization Extensions, then a Translation fault is generated if the
input address for a translation either does not map on to an address range of a Translation Table Base Register, or
the Translation Table Base Register range that it maps on to is disabled.
The architecture guarantees that any translation table entry that causes a Translation fault is not cached,
Access flag fault
An Access flag fault can be generated at any level of lookup,
• The translation tables support an Access flag bit:
— the Short-descriptor format supports an Access flag only when SCTLR.AFE is set to 1
— the Long-descriptor format always supports an Access flag.
The architecture guarantees that any translation table entry that causes an Access flag fault is not cached, meaning
the TLB never holds such an entry.
Domain fault, Short-descriptor format translation tables only
When using the Short-descriptor translation table format, a Domain fault can be generated at the first level or second
level of lookup.
When a first-level/second-level descriptor fetch returns a valid Section first-level descriptor, the domain field of
that descriptor is checked against the DACR. A first-level Domain fault is generated if this check
fails.
A TLB might hold a translation table entry that cause a Domain fault.
Permission fault
A Permission fault can be generated at any level of lookup, and the reported fault code identifies the lookup level.
A TLB might hold a translation table entry that cause a Permission fault. Therefore, if the handling of a Permission
fault results in an update to the associated translation tables, the software that updates the translation tables must
invalidate the appropriate TLB entry.
B3.12.6 External aborts
The ARM architecture defines external aborts as errors that occur in the memory system, other than those that are
detected by the MMU or Debug hardware.An external abort is one of:
• synchronous
• precise asynchronous
• imprecise asynchronous.
The ARM architecture does not provide any method to distinguish between precise asynchronous and imprecise
asynchronous aborts.
Normally, external aborts are rare. An imprecise asynchronous external abort is likely to be fatal to the process that
is running.
B3.12.7 Prioritization of aborts
prioritization decreasing in next order:
- Alignment fault
- an MMU fault, on either the stage 1 translation or the stage 2 translation
- a Watchpoint debug event.
- an external abort
B3.13 Exception reporting in a VMSA implementation
B3.13.1 About exception reporting
In an implementation that includes the Virtualization Extensions, exceptions can be taken to:
• a Secure or Non-secure PL1 mode
• the Non-secure PL2 mode, Hyp mode.
B3.13.2 Reporting exceptions taken to PL1 modes
Registers used for reporting exceptions taken to a PL1 mode
ARMv7 defines the following registers, and register encodings, for exceptions taken to PL1 modes:
• the DFSR holds information about a Data Abort exception
• the DFAR holds the faulting address for some synchronous Data Abort exceptions
• the IFSR holds information about a Prefetch Abort exception
• the IFAR holds the faulting address of a Prefetch Abort exception
• on a Watchpoint debug exception, the DBGWFAR can hold fault information.
Auxiliary Fault Status Registers
The ARMv7 architecture defines the following Auxiliary Fault Status Registers:
• the Auxiliary Data Fault Status Register, ADFSR
• the Auxiliary Instruction Fault Status Register, AIFSR.
B3.13.3 Fault reporting in PL1 modes
Fixme [Table B3-23 Short-descriptor format FSR encodings] Page 1415
Fixme [Table B3-24 Long-descriptor format FSR encodings] Page 1416
B3.13.5 Reporting exceptions taken to the Non-secure PL2 mode
Registers used for reporting exceptions taken to Hyp mode
The Virtualization Extensions define the following registers for exceptions taken to Hyp mode:
• the HSR holds syndrome information for the exception
• the HDFAR holds the VA associated with a Data Abort exception
• the HIFAR holds the VA associated with a Prefetch Abort exception
• the HPFAR holds bits[39:12] of the IPA associated with some aborts on stage 2 address translations.
Hyp Auxiliary Fault Syndrome Registers
The Virtualization Extensions define the following Hyp Auxiliary Fault Syndrome Registers:
• the Hyp Auxiliary Data Fault Syndrome Register, HADFSR
• the Hyp Auxiliary Instruction Fault Syndrome Register, HAIFSR.
Fixme [Table B3-28 HSR.EC encodings for aborts taken to Hyp mode] Page 1422
B3.13.6 Use of the HSR
The HSR holds syndrome information for any synchronous exception taken to Hyp mode. Compared with the
reporting of exceptions taken to PL1 modes, the HSR:
• Always provides details of the fault. The DFSR and IFSR are not used.
• Provides more extensive information, for a wider range of exceptions.
Fixme [Figure B3-25 Format of the HSR, with subdivision of the ISS field for specified EC encodings] Page 1425
Fixme [Table B3-29 HSR.EC field encoding] Page 1425
More detail ISS encoding see arm-arm pdf
B3.14 Virtual Address to Physical Address translation operation
CP15 c7 includes operations for Virtual Address (VA) to Physical Address (PA) translation.
B3.14.1 Naming of the address translation operations, and operation summary
Fixme [Table B3-31 Naming of address translation operations] Page 1438
In the stage 1 current state and stages 1 and 2 Non-secure state only operations, the meanings of the last two letters
of the names are:
- PR PL1 mode, read operation.
- PW PL1 mode, write operation.
- UR PL0 mode, read operation.
- UW PL0 mode, write operation.
B3.14.2 Encoding and availability of the address translation operations
Software executing at PL0 never has any visibility of the address translation operations, but software executing at
PL1 or higher can use the unprivileged address translation operations to find the address translations used for
memory accesses by software executing at PL0 and PL1.
Fixme [Table B3-32 CP15 c7 address translation operations] Page 1440
The result of an operation is always returned in the PAR. The PAR is a RW register and:
• in all implementations, the 32-bit format PAR is accessed using an MCR or MRC instruction with CRn set to c7,
CRm set to c4, and opc1 and opc2 both set to 0
• in an implementation that includes the Large Physical Address Extension, the 64-bit format PAR is accessed
using an MCRR or MRRC instruction with CRm set to c7, and opc1 set to 0.
B3.14.3 Determining the PAR format, Large Physical Address Extension
The Large Physical Address Extension extends the PAR to become a 64-bit register, and supports both 32-bit and
64-bit PAR formats
B3.15 About the system control registers for VMSA
On an ARMv7-A or ARMv7-R implementation, the system control registers comprise:
• the registers accessed using the System Control Coprocessor, CP15
• registers accessed using the CP14 coprocessor, including:
— debug registers
— trace registers
— execution environment registers.
B3.15.3 Classification of system control registers
Banked system control registers
Fixme [Table B3-33 Banked CP15 registers] Page 1452
Restricted access system control registers
Fixme [Table B3-34 Restricted access CP15 registers] Page 1453
PL2-mode system control registers
Fixme [Table B3-35 Banked PL2-mode CP15 read/write registers] Page 1455
Fixme [Table B3-37 Banked PL2-mode CP15 write-only operations] Page 1457
Common system control registers
Some system control registers and operations are common to the Secure and Non-secure security states.
Fixme [Table B3-38 Common CP15 registers] Page 1457
B3.16 Organization of the CP14 registers in a VMSA implementation
The CP14 registers provide a number of distinct control functions, covering:
• Debug
• Trace
• Execution environment control, for the Jazelle and ThumbEE execution environments.
The CP14 register encodings are classified by the {CRn, opc1, CRm, opc2} values required to access them using
an MCR or an MRC instruction. The opc1 value determines the primary allocation of these registers, as follows:
opc1==0 Debug registers.
opc1==1 Trace registers.
opc1==6 ThumbEE registers.
opc1==7 Jazelle registers. Can include Jazelle SUBARCHITECTURE DEFINED registers
B3.17 Organization of the CP15 registers in a VMSA implementation
More precisely, the ordered set of values {CRn, opc1, CRm, opc2} determined the register order.
B3.17.1 CP15 register summary by coprocessor register number
Fixme [Figure B3-26 CP15 register grouping by primary coprocessor register, CRn, VMSA implementation] Page 1470
VMSA CP15 c0 register summary, identification registers
Fixme [Figure B3-27 CP15 c0 registers in a VMSA implementation] Page 1471
VMSA CP15 c1 register summary, system control registers
Fixme [Figure B3-28 CP15 c1 registers in a VMSA implementation] Page 1472
VMSA CP15 c2 and c3 register summary, Memory protection and control registers
Fixme [Figure B3-29 CP15 32-bit c2 and c3 registers] Page 1473
Fixme [Figure B3-30 CP15 64-bit c2 registers] Page 1473
VMSA CP15 c5 and c6 register summary, Memory system fault registers
Fixme [Figure B3-31 CP15 c5 and c6 registers in a VMSA implementation] Page 1474
VMSA CP15 c7 register summary, Cache maintenance, address translation, and other functions
Fixme [Figure B3-32 CP15 32-bit c7 registers in a VMSA implementation] Page 1475
VMSA CP15 c8 register summary, TLB maintenance operations
Fixme [Figure B3-34 CP15 c8 registers in a VMSA implementation] Page 1476
VMSA CP15 c9 register summary, reserved for cache and TCM control and performance monitors
Fixme [Figure B3-35 Reserved CP15 c9 encodings] Page 1477
VMSA CP15 c10 register summary, memory remapping and TLB control registers
Fixme [Figure B3-36 CP15 c10 registers in a VMSA implementation] Page 1478
VMSA CP15 c11 register summary, reserved for TCM DMA registers
Fixme [Figure B3-37 Reserved CP15 c11 encodings] Page 1478
VMSA CP15 c12 register summary, Security Extensions registers
Fixme [Figure B3-38 Security Extensions CP15 c12 registers] Page 1479
VMSA CP15 c13 register summary, Process, context and thread ID registers
On an ARMv7-A implementation, the CP15 c13 registers provide:
• an FCSE Process ID Register, that indicates whether the implementation includes the FCSE
• a Context ID Register
• Software Thread ID Registers.
Fixme [Figure B3-39 CP15 c13 registers in a VMSA implementation] Page 1479
VMSA CP15 c14, reserved for Generic Timer Extension
Fixme [Figure B3-40 CP15 32-bit c14 registers in a VMSA implementation that includes the Generic Timer Extension] Page 1480
Fixme [Figure B3-41 CP15 64-bit c14 registers in a VMSA implementation that includes the Generic Timer Extension] Page 1480
VMSA CP15 c15 register summary, IMPLEMENTATION DEFINED registers
B3.17.2 Full list of VMSA CP15 registers, by coprocessor register number
Fixme [Table B3-42 Summary of VMSA CP15 register descriptions, in coprocessor register number order] Page 1481
B3.18 Functional grouping of VMSAv7 system control registers
B3.18.1 Identification registers, functional group
Fixme [Table B3-44 Identification registers, VMSA] Page 1492
B3.18.2 Virtual memory control registers, functional group
Fixme [Table B3-45 Virtual memory control registers, VMSA only] Page 1493
B3.18.3 PL1 Fault handling registers, functional group
Fixme [Table B3-46 Fault handling registers, VMSA] Page 1494
B3.18.4 Other system control registers, functional group
Fixme [Table B3-47 Other system control registers, VMSA] Page 1494
B3.18.5 Lockdown, DMA, and TCM features, functional group, VMSA
Fixme [Table B3-48 Lockdown, DMA, and TCM features, VMSA] Page 1495
B3.18.6 Cache maintenance operations, functional group, VMSA
Fixme [Table B3-49 Cache and branch predictor maintenance operations, VMSA] Page 1496
B3.18.7 TLB maintenance operations, functional group
Fixme [Table B3-50 TLB maintenance operations, VMSA only] Page 1497
B3.18.8 Address translation operations, functional group
Fixme [Table B3-51 Address translation operations, VMSA only] Page 1498
B3.18.9 Miscellaneous operations, functional group
Fixme [Table B3-52 Miscellaneous system control operations, VMSA only] Page 1499
B3.18.10 Performance Monitors, functional group
Fixme [Table B3-53 Performance monitors, VMSA] Page 1500
B3.18.11 Security Extensions registers, functional group
Fixme [Table B3-54 Security Extensions registers, VMSA only] Page 1500
B3.18.12 Virtualization Extensions registers, functional group
Fixme [Table B3-55 Virtualization Extensions registers, VMSA with Virtualization Extensions only] Page 1501
Fixme [Table B3-56 Hyp mode TLB maintenance operations, VMSA with Virtualization Extensions only] Page 1502
B3.18.13 Generic Timer Extension registers
B3.18.14 IMPLEMENTATION DEFINED registers, functional group
Typically, an implementation uses CP15 c15 to provide test features, and any required configuration options that
are not covered by this manual.
B4 System Control Registers in a VMSA implementation
Skip
B5 Protected Memory System Architecture (PMSA)
Skip
B6 System Control Registers in a PMSA implementation
Skip
B7 The CPUID Identification Scheme
B7.1 Introduction to the CPUID scheme
Before ARMv7, using Main ID Register:
• MIDR, Main ID Register, VMSA on page B4-1649
• MIDR, Main ID Register, PMSA on page B6-1894.
The ARMv7 architecture implements an extended processor, using a number of registers in CP15 c0.
ARMv7 requires the use of this scheme, and use of the scheme is indicated by a value of 0xF in the Architecture field of the Main ID Register.
The CPUID scheme provides information about the implemented:
• processor features
• debug features
• auxiliary features, in particular IMPLEMENTATION DEFINED features
• memory model features
• instruction set features.
B7.2 The CPUID registers
B7.2.1 Organization of the CPUID registers
Fixme[Figure B7-1 CPUID register encodings] Page 1951
Fixme[Table B7-1 CPUID register summary] Page 1952
B7.2.2 About the Instruction Set Attribute registers
Fixme[Table B7-2 Alphabetic list of Instruction Set Attribute registers attribute fields] Page 1954
B8. The Generic Timer
B8.1 About the Generic Timer
Fixme[Figure B8-1 Generic Timer example] page1960
8.1.1 System counter
The Generic Timer provides a system counter with the following specification:
Width
At least 56 bits wide.
The value returned by any 64-bit read of the counter is zero-extended to 64 bits.
Frequency
Increments at a fixed frequency, typically in the range 1-50MHz.
Can support one or more alternative operating modes in which it increments by larger amounts at a
lower frequency, typically for power-saving.
Roll-over Roll-over time of not less than 40 years.
Accuracy
ARM does not specify a required accuracy, but recommends that the counter does not gain or lose
more than ten seconds in a 24-hour period.
Use of lower-frequency modes must not affect the implemented accuracy.
Start-up
Starts operating from zero.
The system counter must be implemented in an always-on power domain.
Initializing and reading the system counter frequency
Typically, the system drives the system counter at a fixed frequency and the CNTFRQ register must be programmed
to this value during the system boot process.
In an implementation that supports the ARM Security Extensions, only
software executing in a Secure PL1 mode can write to CNTFRQ.
Software can read the CNTFRQ register, to determine the current system counter frequency, in the following states
and modes:
• Non-secure PL2 mode.
• Secure and Non-secure PL1 modes.
• When CNTKCTL.PL0PCTEN is set to 1, Secure and Non-secure PL0 modes.
8.1.2 The physical counter
The processor provides a physical counter that contains the count value of the system counter. The CNTPCT register
holds the current physical counter value.
In an implementation that includes the Virtualization Extensions, CNTPCT:
• Is always accessible from Secure PL1 modes, and from Non-secure Hyp mode.
• Is accessible from Non-secure PL1 modes only when CNTHCTL.PL1PCTEN is set to 1. When
CNTHCTL.PL1PCTEN is set to 0, any attempt to access CNTPCT from a Non-secure PL1 mode generates
a Hyp Trap exception, see Hyp Trap exception on page B1-1209.
8.1.3 The virtual counter
An implementation of the Generic Timer always includes a virtual counter, that indicates virtual time:
• In a processor implementation that does not include the Virtualization Extensions, virtual time is identical to
physical time, and the virtual counter contains the same value as the physical counter.
• In a processor implementation that includes the Virtualization Extensions, the virtual counter contains the
value of the physical counter minus a 64-bit virtual offset. When execu
CNTVCT is always accessible from Secure PL1 modes, and from Non-secure PL1 and PL2 modes
8.1.5 Timers
The number of timers provided by an implementation of the Generic Timer depends on whether the implementation
includes the Security Extensions and the Virtualization Extensions, as follows:
Security Extensions not implemented
The implementation provides a physical timer and a virtual timer.
Security Extensions implemented, Virtualization Extensions not implemented
The implementation provides:
- A Non-secure physical timer.
- A Secure physical timer.
- A virtual timer.
Virtualization Extensions implemented
The implementation provides:
- A Non-secure PL1 physical timer.
- A Secure PL1 physical timer.
- A Non-secure PL2 physical timer.
- A virtual timer
Each timer is implemented as three registers:
- A 64-bit CompareValue register, that provides a 64-bit unsigned upcounter.
- A 32-bit TimerValue register, that provides a 32-bit signed downcounter.
- A 32-bit Control register.
Fixme[Table B8-1 Timer registers summary for the Generic Timer] page1965
8.2 Generic Timer registers summary
Fixme[Table B8-2 Generic Timer registers] page1969