Virtualization Extensions
Are an OPTIONAL set of extensions to VMSAv7 that provides hardware support for virtualizing the
Non-secure state of a VMSAv7 implementation. This supports system use of a virtual machine
monitor, also called a hypervisor, to switch Guest operating systems.
The Virtualization Extensions require implementation of:
• The Security Extensions.
• The Large Physical Address Extension.
• The v7.1 Debug architecture, see Scope of part C of this manual on page C1-2008.
If an implementation that includes the Virtualization Extensions also implements:
• The Performance Monitors Extension, then it must implement version 2 of that extension,
PMUv2, see About the Performance Monitors on page C12-2288.
• A trace macrocell, that trace macrocell must support the Virtualization Extensions. In
particular,if the trace macrocell is:
— An Embedded Trace Macrocell(ETM), the macrocell must implement ETMv3.5 or
later, see the Embedded Trace Macrocell Architecture Specification.
— A Program Trace Macrocell(PTM), the macrocell must implement PFTv1.1 or later,
see the CoreSight Program Flow Trace Architecture Specification.
In some tables in this manual, an ARMv7-A implementation that includes the Virtualization
Extensions is described as ARMv7VE, or as v7VE.
P101
Exceptions include:
• Reset.
• Interrupts.
• Memory system aborts.
• Undefined instructions.
• Supervisor calls(SVCs), Secure Monitor calls(SMCs), and hypervisor calls(HVCs)
In an implementation that includes the Virtualization Extensions, the HVC instruction causes a
Hypervisor Call exception, but only if software execution is at PL1 or higher. Unprivileged
software can only cause a Hypervisor Call exception by methods defined by the hypervisor,
or by another component of the software system that executes at PL1 or higher.
P139
The characteristics of the privilege levels are:
PL1
Software execution in all modes other than User mode and Hyp mode is at PL1. Normally, operating
system software executes at PL1. Software executing at PL1 can access all features of the
architecture, and can change the configuration settings for those features, except for some features
added by the Virtualization Extensions that are only accessible at PL2.
Note
In many implementation models, system software is unaware of the PL2 level of privilege, and of
whether the implementation includes the Virtualization Extensions.
The PL1 modes refers to all the modes other than User mode and Hyp mode.
Software executing at PL1 makes privileged memory accesses by default, but can also make
unprivileged accesses.
PL2
Software executing in Hyp mode executes at PL2.
Software executing at PL2 can perform all of the operations accessible at PL1, and can access some
additional functionality.
Hyp mode is normally used by a hypervisor, that controls, and can switch between, Guest OSs, that
execute at PL1.
Hyp mode is implemented only as part of the Virtualization Extensions, and only in Non-secure
state. This means that:
• Implementations that do not include the Virtualization Extensions have only two privilege
levels, PL0 and PL1.
• Execution in Secure state has only two privilege levels, PL0 and PL1.
In an implementation that includes the Security Extensions, the execution privilege levels are defined independently
in each security state, and there is no relationship between the Secure and Non-secure privilege levels.
Note
The fact that Non-secure Hyp mode executes at PL2 does not indicate that it is more privileged than the Secure PL1
modes. Secure PL1 modes can change the configuration and control settings for Non-secure operation in all modes,
but Non-secure modes can never change the configuration and control settings for Secure operation.
Memory access permissions can be assigned:
• At PL1,for accesses made at PL1 and at PL0.
• In Non-secure state, at PL2, independently for:
— Non-secure accesses made at PL2.
— Non-secure accesses made at PL1, and at PL0.
P142
An ARMv7-A processor that implements the Virtualization Extensions provides two stages of
address translation for processes running at the Application level:
• The operating system defines the mappings from virtual addresses to intermediate physical
addresses(IPAs). When it does this, it believes it is mapping virtual addresses to physical
addresses.
• The hypervisor defines the mappings from IPAs to physical addresses. These translations are
invisible to the operating system.
P1139
ARM processor modes
P1141
Hyp mode
Hyp mode is a Non-secure mode, implemented only as part of the Virtualization Extensions. It provides the usual
method of controlling almost all of the functionality of the Virtualization Extensions.
Note
The alternative method of controlling this functionality is by accessing the Hyp mode controls from Secure Monitor
mode, with the SCR.NS bit set to 1.
This section summarizes how Hyp mode differs from the other modes, and references where the features of Hyp
mode are described in more detail:
• Software executing in Hyp mode executes at PL2, see Mode, state, and privilege level on page B1-1135.
• Hyp mode is accessible only in Non-secure state. When the processor is in Secure state, setting CPSR.M to
0b11010 , the encoding for Hyp mode, has no meaning. Therefore, in Secure state, the effect of attempting to
set CPSR.M to 0b11010 is UNPREDICTABLE . For more information see The Current Program Status Register(CPSR) on page B1-1147.
• In Non-debug state, the only mechanisms for changing to Hyp mode are:
— An exception taken from a Non-secure PL1 or PL0 mode.
— An exception return from Secure Monitor mode.
• In Hyp mode, the only exception return is execution of an ERET instruction, see ERET on page B9-1968.
• 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-721.
• The effect of an exception return with the restored CPSR specifying Hyp mode is UNPREDICTABLE if either:
— SCR.NS is set to 0.
— The return is from a Non-secure PL1 mode.
• The instructions described in the following sections are UNDEFINED if executed in Hyp mode:
— SRS(Thumb) on page B9-1990.
— SRS(ARM) on page B9-1992.
— RFE on page B9-1986.
— LDM(exception return) on page B9-1972.
— LDM(User registers) on page B9-1974.
— STM(User registers) on page B9-1994.
— SUBS PC, LR and related instructions(ARM) on page B9-1998.
— SUBS PC,LR(Thumb) on page B9-1996, when executed with a nonzero constant.
Note
In Thumb state, ERET is encoded as SUBS PC, LR, #0, and therefore this is a valid instruction.
• The unprivileged Load unprivileged and Store unprivileged instructions LDRT , LDRSHT , LDRHT , LDRBT , STRT ,
STRHT , and STRBT , are UNPREDICTABLE if executed in Hyp mode.
From reset, the HVC instruction is UNDEFINED in Non-secure PL1 modes, meaning entry to Hyp mode is disabled by
default. To permit entry to Hyp mode using the Hypervisor Call exception, Secure software must enable use of the
HVC instruction by setting the SCR.HCE bit to 1. In addition, when SCR.HCE is set to 0, HVC is UNPREDICTABLE in
Hyp mode.
扫一扫
858
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
