| Document number: | DEN0137 |
| Document quality: | ALP |
| Document version: | 1.1-alp8alp9 |
| Document confidentiality: | Non-confidential |
| Document Build Information: |
Contents
Preface
Quality level
This table below summarises the quality level of the features which have been added in version 1.1 of this specification.
| Feature | Quality level |
|---|---|
| Realm device assignment | ALPHA |
| Planes | BETA |
| Realm memory encryption | BETA |
| Live firmware activation | ALPHA |
| Platform software component countersigners | BETA |
Due to the fact that some features are at ALPHA, the overall quality level of this version of the specification is ALPHA.
Conventions
Typographical conventions
The typographical conventions are:
italic
Introduces special terminology, and denotes citations.
monospace
Used for pseudocode and source code examples.
Also used in the main text for instruction mnemonics and for references to other items appearing in pseudocode and source code examples.
small capitals
Used for some common terms such as implementation defined.
Used for a few terms that have specific technical meanings, and are included in the Glossary.
Red text
Indicates an open issue.
Blue text
Indicates a link. This can be
- A cross-reference to another location within the document
- A URL, for example http://developer.arm.com
Numbers
Numbers are normally written in decimal. Binary numbers are preceded
by 0b, and hexadecimal numbers by 0x. In both
cases, the prefix and the associated value are written in a monospace
font, for example 0xFFFF0000. To improve readability, long
numbers can be written with an underscore separator between every four
characters, for example 0xFFFF_0000_0000_0000. Ignore any
underscores when interpreting the value of a number.
Pseudocode descriptions
This book uses a form of pseudocode to provide precise descriptions of the specified functionality. This pseudocode is written in a monospace font. The pseudocode language is described in the Arm Architecture Reference Manual.
Addresses
Unless otherwise stated, the term address in this specification refers to a physical address.
Rules-based writing
This specification consists of a set of individual content items. A content item is classified as one of the following:
- Declaration
- Rule
- Goal
- Information
- Rationale
- Implementation note
- Software usage
Declarations and Rules are normative statements. An implementation that is compliant with this specification must conform to all Declarations and Rules in this specification that apply to that implementation.
Declarations and Rules must not be read in isolation. Where a particular feature is specified by multiple Declarations and Rules, these are generally grouped into sections and subsections that provide context. Where appropriate, these sections begin with a short introduction.
Arm strongly recommends that implementers read all chapters and sections of this document to ensure that an implementation is compliant.
Content items other than Declarations and Rules are informative statements. These are provided as an aid to understanding this specification.
Content item identifiers
A content item may have an associated identifier which is unique among content items in this specification.
After this specification reaches beta status, a given content item has the same identifier across subsequent versions of the specification.
Content item rendering
In this document, a content item is rendered with a token of the following format in the left margin: Liiiii
- L is a label that indicates the content class of the content item.
- iiiii is the identifier of the content item.
Content item classes
Declaration
A Declaration is a statement that does one or more of the following:
- Introduces a concept
- Introduces a term
- Describes the structure of data
- Describes the encoding of data
A Declaration does not describe behaviour.
A Declaration is rendered with the label D.
Rule
A Rule is a statement that describes the behaviour of a compliant implementation.
A Rule explains what happens in a particular situation.
A Rule does not define concepts or terminology.
A Rule is rendered with the label R.
Goal
A Goal is a statement about the purpose of a set of rules.
A Goal explains why a particular feature has been included in the specification.
A Goal is comparable to a “business requirement” or an “emergent property.”
A Goal is intended to be upheld by the logical conjunction of a set of rules.
A Goal is rendered with the label G.
Information
An Information statement provides information and guidance as an aid to understanding the specification.
An Information statement is rendered with the label I.
Rationale
A Rationale statement explains why the specification was specified in the way it was.
A Rationale statement is rendered with the label X.
Implementation note
An Implementation note provides guidance on implementation of the specification.
An Implementation note is rendered with the label U.
Software usage
A Software usage statement provides guidance on how software can make use of the features defined by the specification.
A Software usage statement is rendered with the label S.
Additional reading
This section lists publications by Arm and by third parties.
See Arm Developer (http://developer.arm.com) for access to Arm documentation.
Feedback
Arm welcomes feedback on its documentation.
Feedback on this book
If you have any comments or suggestions for additions and improvements, create a ticket at https://support.developer.arm.com/. As part of the ticket, include:
- The title (Realm Management Monitor specification).
- The number (DEN0137 1.1-alp8alp9).
- The section name(s) to which your comments refer.
- The page number(s) to which your comments apply.
- The rule identifier(s) to which your comments apply, if applicable.
- A concise explanation of your comments.
Arm also welcomes general suggestions for additions and improvements.
Arm tests PDFs only in Adobe Acrobat and Acrobat Reader, and cannot guarantee the appearance or behavior of any document when viewed with any other PDF reader.
Open issues
The following table lists known open issues in this version of the document.
| Key | Description |
|---|---|
| - | Consider prefixing states with a namespace, for example changing DEV_PRIVATE to GRANULE_DEV_PRIVATE. This would avoid potential confusion with the RmiDevMemShared and RmmDevMemShared values. |
| - | State rules concerning Selective IDE and Link IDE streams. -Consider how teardown of DRAM mappings (via RMI_DATA_DESTROY) composes with teardown of device memory mappings (via RMI_DEV_MEM_UNMAP). In each case, the command returns the IPA of the next live entry - but it doesn’t tell the caller whether this is DRAM or IO. How then can the caller know which of the two commands to call next, while still avoiding a (race-prone) call to RMI_RTT_READ_ENTRY? |
| - | In RMI_RTT_SET_RIPAS, consider how to combine:
|
1 Overview
The RMM is a software component which forms part of a system which implements the Arm Confidential Compute Architecture (Arm CCA). Arm CCA is an architecture which provides protected execution environments called Realms.
The threat model which Arm CCA is designed to address is described in Introducing Arm CCA [1].
The hardware architecture of Arm CCA is called the Realm Management Extension (RME), and is described in Arm Architecture Reference Manual Supplement, The Realm Management Extension (RME), for Armv9-A [2].
1.1 Confidential computing
The Armv8-A architecture (Arm Architecture Reference Manual for A-Profile architecture [3]) includes mechanisms that establish a privilege hierarchy. Software operating at higher privilege levels is responsible for managing the resources (principally memory and processor cycles) that are used by entities at lower privilege levels.
Prior to Arm CCA, resource management was coupled with a right of access. That is, a resource that is managed by a higher-privileged entity is also accessible by it. A Realm is a protected execution environment for which this coupling is broken, so that the right to manage resources is separated from the right to access those resources.
The purpose of a Realm is to provide to the Realm owner an environment for confidential computing, without requiring the Realm owner to trust the software components that manage the resources used by the Realm.
Construction of a Realm, and allocation of resources to a Realm at runtime, are the responsibility of the Virtual Machine Monitor (VMM). In this specification, the term Host is used to refer to the VMM.
See also:
- Section 2.1
1.2 System software components
The system software architecture of Arm CCA is summarised in the following figure.
The components shown in the diagram are listed below.
| Component | Description |
|---|---|
| Monitor | The most privileged software component, which is responsible for switching between the Security states used at EL2, EL1 and EL0. |
| Realm | A protected execution environment. |
| Realm Management Monitor (RMM) | The software component which is responsible for the management of Realms. |
| Virtual Machine (VM) | An execution environment within which an operating system can run. Note that a Realm is a VM which executes in the Realm security state. |
| Hypervisor | The software component which is responsible for the management of VMs. |
| Secure Partition Manager (SPM) | The software component which is responsible for the management of Secure Partitions. |
| Trusted OS (TOS) | An operating system which runs in a Secure Partition. |
| Trusted Application (TA) | An application hosted by a TOS. |
1.3 Realm Management Monitor
The Realm Management Monitor (RMM) is the system component that is responsible for the management of Realms.
The responsibilities of the RMM are to:
Provide services that allow the Host to create, populate, execute and destroy Realms.
Provide services that allow the initial configuration and contents of a Realm to be attested.
Protect the confidentiality and integrity of Realm state during the lifetime of the Realm.
Protect the confidentiality of Realm state during and following destruction of the Realm.
Act as the Trusted Security Manager (TSM) in Realm device assignment.
The RMM exposes the following interfaces, which are accessed via SMC instructions, to the Host:
- The Realm Management Interface (RMI), which provides services for the creation, population, execution and destruction of Realms.
The RMM exposes the following interfaces, which are accessed via SMC instructions, to Realms:
The Realm Services Interface (RSI), which provides services used to manage resources allocated to the Realm, and to request an attestation report.
The Power State Coordination Interface (PSCI), which provides services used to control power states of VPEs within a Realm. Note that the HVC conduit for PSCI is not supported for Realms.
The RMM operates by manipulating data structures which are stored in memory accessible only to the RMM.
2 Concepts
This chapter introduces the following concepts which are central to the RMM architecture:
2.1 Realm
This section describes the concept of a Realm.
2.1.1 Overview
A Realm is an execution environment which is protected from agents in the Non-secure and Secure Security states, and from other Realms.
2.1.2 Realm execution environment
The execution environment of a Realm is an EL0 + EL1 environment, as described in Arm Architecture Reference Manual for A-Profile architecture [3].
2.1.2.1 Realm registers
On first entry to a Realm VPE, PE state is initialized according to “PE state on reset to AArch64 state” in Arm Architecture Reference Manual for A-Profile architecture [3], except for GPR and PC values which are specified by the Host during Realm creation.
Confidentiality is guaranteed for a Realm VPE’s general purpose and SIMD / floating point registers.
Confidentiality is guaranteed for other Realm VPE register state (including stack pointer, program counter and EL0 / EL1 system registers).
Integrity is guaranteed for a Realm VPE’s general purpose and SIMD / floating point registers.
Integrity is guaranteed for other Realm VPE register state (including stack pointer, program counter and EL0 / EL1 system registers).
A Realm can use a Host call to pass arguments to the Host and receive results from the Host.
2.1.2.2 Realm memory
A Realm is able to determine whether a given IPA is protected or unprotected.
Confidentiality is guaranteed for memory contents accessed via a protected address. Informally, this means that a change to the contents of such a memory location is not observable by any agent outside the CCA platform.
Integrity is guaranteed for memory contents accessed via a protected address. Informally, this means that the Realm does not observe the contents of the location to change unless the Realm itself has either written a different value to the location, or provided consent to the RMM for integrity of the location to be violated.
See also:
- Section 5.2.1
2.1.2.3 Realm processor features
The value returned to a Realm from reading a feature register is architecturally valid and describes the set of features which are present in the Realm’s execution environment.
The RMM may suppress a feature which is supported by the underlying hardware platform, if exposing that feature to a Realm could lead to a security vulnerability.
See also:
- Section 3
2.1.2.4 IMPDEF system registers
A Realm read from or write to an implementation defined system register causes an Unknown exception taken to the Realm.
2.1.3 Realm attributes
This section describes the attributes of a Realm.
A Realm attribute is a property of a Realm whose value can be observed or modified either by the Host or by the Realm.
An example of a way in which a Realm attribute may be observable is the outcome of an RMM command.
The attributes of a Realm are summarized in the following table.
| Name | Type | Description |
|---|---|---|
| feat_lpa2 | RmmFeature | Whether LPA2 is enabled for this Realm |
| ipa_width | UInt8 | IPA width in bits |
| measurements | RmmRealmMeasurement[5] | Realm measurements |
| hash_algo | RmmHashAlgorithm | Algorithm used to compute Realm measurements |
| rec_index | UInt64 | Index of next REC to be created |
| rtt_base | Address[4] | Realm Translation Table base addresses If rtt_tree_pp is FEATURE_FALSE then only the first entry is valid. If rtt_tree_pp is FEATURE_TRUE then only the first (num_aux_planes + 1) entries are valid. |
| rtt_level_start | Int64 | RTT starting level |
| rtt_num_start | UInt64 | Number of physically contiguous starting level RTTs |
| state | RmmRealmState | Lifecycle state |
| vmid | Bits16[4] | Virtual Machine Identifiers If rtt_tree_pp is FEATURE_FALSE then only the first entry is valid. If rtt_tree_pp is FEATURE_TRUE then only the first (num_aux_planes + 1) entries are valid. |
| rpv | Bits512 | Realm Personalization Value |
| feat_da | RmmFeature | Whether Realm device assignment is enabled for this Realm |
| rtt_tree_pp | RmmFeature | Whether this Realm has an RTT per Plane |
| num_aux_planes | UInt64 | Number of auxiliary Planes |
| overlay_perms | RmmMemPerms[4] | Memory overlay permissions |
| overlay_locked | RmmMemPermLocked[16] | Whether memory overlay value is locked |
| lfa_policy | RmmLfaPolicy | Live Firmware Activation policy for components within the Realm’s TCB |
| mecid | Bits64 | Memory Encryption Context Identifier |
| mec_policy | RmmMecPolicy | MEC policy |
| num_recs | UInt64 | Number of RECs owned by this Realm |
| num_vdevs | UInt64 | Number of VDEVs which have been assigned to this Realm |
A Realm Initial Measurement (RIM) is a measurement of the configuration and contents of a Realm at the time of activation.
A Realm Extensible Measurement (REM) is a measurement value which can be extended during the lifetime of a Realm.
Attributes of a Realm include an array of measurement values. The first entry in this array is a RIM. The remaining entries in this array are REMs.
During Realm creation, the Host provides ipa_width, rtt_level_start and rtt_num_start values as Realm parameters. According to the VMSA, the rtt_num_start value is architecturally defined as a function of the ipa_width and rtt_level_start values. It would therefore have been possible to design the Realm creation interface such that the Host provided only the ipa_width and rtt_level_start values. However, this would potentially allow a Realm to be successfully created, but with a configuration which did not match the Host’s intent. For this reason, it was decided that the Host should specify all three values explicitly, and that Realm creation should fail if the values are not consistent. See Arm Architecture Reference Manual for A-Profile architecture [3] for further details.
The VMID of a Realm is chosen by the Host. The VMID must be within the range supported by the hardware platform. The RMM ensures that every Realm on the system has a unique VMID.
A Realm Personalization Value (RPV) is a provided by the Host, to distinguish between Realms which have the same Realm Initial Measurement, but different behavior.
Possible uses of the RPV include:
- A GUID
- Hash of Realm Owner public key
- Hash of a “personalisation document” which is provided to the Realm via a side-band (for example, via NS memory) and contains configuration information used by Realm software.
The RMM treats the RPV as an opaque value.
The RPV is included in the Realm attestation report as a separate claim.
The RPV is included in the output of the RSI_REALM_CONFIG command.
If Realm device assignment is not enabled for a Realm then all of the following are true:
- Assignment of a virtual device to the Realm by execution of RMI_VDEV_CREATE fails.
- The device assignment feature is reported to the Realm by RSI_FEATURES as not enabled. Consequently, execution of any RSI_RDEV command fails.
See also:
2.1.4 Realm liveness
Realm liveness is a property which means that there exists one or more Granules, other than the RD and the starting level RTTs, which are owned by the Realm.
If a Realm is live, it cannot be destroyed.
A Realm is not zero A starting level RTT of the Realm is live A Realm is live if any of the following is true:
- The number of RECs owned by the Realm is not zero
- A starting level RTT of the Realm is live
If a Realm owns a non-zero number of Data Granules, this implies that it has a starting level RTT which is live, and therefore that the Realm itself is live.
See also:
2.1.5 Realm lifecycle
2.1.5.1 States
The states of a Realm are listed below.
| State | Description |
|---|---|
| REALM_NEW | Under construction. Not eligible for execution. |
| REALM_ACTIVE | Eligible for execution. |
| REALM_SYSTEM_OFF | System has been turned off. Not eligible for execution. |
2.1.5.2 State transitions
Permitted Realm state transitions are shown in the following table. The rightmost column lists the events which can cause the corresponding state transition.
A transition from the pseudo-state NULL represents creation of a Realm object. A transition to the pseudo-state NULL represents destruction of a Realm object.
| From state | To state | Events |
|---|---|---|
| NULL | REALM_NEW | RMI_REALM_CREATE |
| REALM_NEW | NULL | RMI_REALM_DESTROY |
| REALM_ACTIVE | NULL | RMI_REALM_DESTROY |
| REALM_SYSTEM_OFF | NULL | RMI_REALM_DESTROY |
| REALM_NEW | REALM_ACTIVE | RMI_REALM_ACTIVATE |
| REALM_ACTIVE | REALM_SYSTEM_OFF |
Permitted Realm state transitions are shown in the following figure. Each arc is labeled with the events which can cause the corresponding state transition.
A transition from the pseudo-state NULL represents creation of an RD. A transition to the pseudo-state NULL represents destruction of an RD.
Permitted
2.1.6 Realm parameters
A Realm parameter is a value which is provided by the Host during Realm creation.
2.1.7 Realm Descriptor
A Realm Descriptor (RD) is an RMM data structure which stores attributes of a Realm.
The size of an RD is one Granule.
2.2 Granule
This section describes the concept of a Granule.
A Granule is a unit of physical memory whose size is 4KB.
A Granule may be used for one of the following purposes:
- To store code or data used by the Host
- To store code or data used by software in the Secure Security state
- To store code or data used by a Realm
- To access device memory, such as a memory-mapped register interface
- To store data used by the RMM to manage a Realm
The use of a Granule is reflected in its lifecycle state.
To store code or data used by the Host To store code or data used by software in the Secure Security state To store code or data used by a Realm To access device memory, such as a memory-mapped register interface To store data used by the RMM to manage a Realm A Granule may be used for one of the following purposes:A Granule is delegable if it can be delegated by the Host for use by the RMM or by a Realm.
In a typical implementation, delegable memory includes memory which is carved out for use by the Root world, the RMM or the Secure world is presented to the Host as RAM.
Examples of non-delegable memory may include the following:
In a typical implementation- Memory which is carved out for use by the Root world, delegable memory includes memory which is presented to the Host as RAM.the RMM or the Secure world
In a system which supports Realm device assignment, delegable memory includes device memory (that is, regions of the system physical address map which are reserved for use as PCIe device BARs).
The initial state of delegable memory reflects whether it is:
- Delegable DRAM (initial state is UNDELEGATED), or
- Delegable device memory (initial state is DEV_UNDELEGATED)
2.2.1 Granule attributes
This section describes the attributes of a Granule.
A Granule attribute is a property of a Granule whose value can be observed or modified either by the Host or by a Realm.
Examples of ways in which a Granule attribute may be observable include the outcome of an RMM command, and whether a memory access generates a fault.
The attributes of a Granule are summarized in the following table.
| Name | Type | Description |
|---|---|---|
| gpt | RmmGptEntry | GPT entry |
| state | RmmGranuleState | Lifecycle state |
2.2.2 Granule lifecycle
2.2.2.1 States
The states of a Granule are listed below.
For each state, the corresponding GPT entry value is shown.
| Granule state | Description | GPT entry |
|---|---|---|
| UNDELEGATED | Not delegated for use by the RMM. | Not GPT_REALM |
| DELEGATED | Delegated for use by the RMM. | GPT_REALM |
| RD | Realm Descriptor. | GPT_REALM |
| REC | Realm Execution Context. | GPT_REALM |
| REC_AUX | Realm Execution Context auxiliary Granule. | GPT_REALM |
| DATA | Realm code or data. | GPT_REALM |
| RTT | Realm Translation Table. | GPT_REALM |
| PDEV | Physical device. | GPT_REALM |
| PDEV_AUX | Physical device auxiliary Granule. | GPT_REALM |
| VDEV | Virtual device. | GPT_REALM |
| DEV_UNDELEGATED | Device memory, not delegated for use by the RMM. | Not GPT_REALM |
| DEV_DELEGATED_PRIVATE | Device memory, delegated to the RMM and accessible via Realm PAS only. | GPT_REALM |
| DEV_DELEGATED_SHARED | Device memory, delegated to the RMM and accessible via any PAS. | GPT_AAP |
| DEV_PRIVATE | Device memory, mapped into a Realm and inaccessible by other requestors. | GPT_REALM |
| DEV_SHARED | Device memory, mapped into a Realm and also accessible by other requestors. | GPT_AAP |
Consider prefixing states with a namespace, for example changing DEV_PRIVATE to GRANULE_DEV_PRIVATE. This would avoid potential confusion with the RmiDevMemShared and RmmDevMemShared values.
If the state of a Granule is UNDELEGATED or DEV_UNDELEGATED then the RMM does not prevent the GPT entry of the Granule from being changed by another agent to any value except GPT_REALM.
An NS Granule is a Granule whose GPT entry is GPT_NS.
2.2.2.2 State transitions
Permitted Granule state transitions are shown in the following table. The rightmost column lists the events which can cause the corresponding state transition.
| From state | To state | Events |
|---|---|---|
| UNDELEGATED | DELEGATED | RMI_GRANULE_DELEGATE |
| DELEGATED | UNDELEGATED | RMI_GRANULE_UNDELEGATE |
| DELEGATED | RD | RMI_REALM_CREATE |
| RD | DELEGATED | RMI_REALM_DESTROY |
| DELEGATED | DATA | |
| DATA | DELEGATED | RMI_DATA_DESTROY |
| DELEGATED | REC | RMI_REC_CREATE |
| REC | DELEGATED | RMI_REC_DESTROY |
| DELEGATED | REC_AUX | RMI_REC_CREATE |
| REC_AUX | DELEGATED | RMI_REC_DESTROY |
| DELEGATED | RTT | |
| RTT | DELEGATED | |
| DELEGATED | PDEV | RMI_PDEV_CREATE |
| PDEV | DELEGATED | RMI_PDEV_DESTROY |
| DELEGATED | PDEV_AUX | RMI_PDEV_CREATE |
| PDEV_AUX | DELEGATED | RMI_PDEV_DESTROY |
| DELEGATED | VDEV | RMI_VDEV_CREATE |
| VDEV | DELEGATED | RMI_VDEV_DESTROY |
| DEV_UNDELEGATED | DEV_DELEGATED_PRIVATE | RMI_GRANULE_DEV_DELEGATE |
| DEV_DELEGATED_PRIVATE | DEV_UNDELEGATED | RMI_GRANULE_DEV_UNDELEGATE |
| DEV_UNDELEGATED | DEV_DELEGATED_SHARED | RMI_GRANULE_DEV_DELEGATE |
| DEV_DELEGATED_SHARED | DEV_UNDELEGATED | RMI_GRANULE_DEV_UNDELEGATE |
| DEV_DELEGATED_PRIVATE | DEV_PRIVATE | RMI_DEV_MEM_MAP |
| DEV_PRIVATE | DEV_DELEGATED_PRIVATE | RMI_DEV_MEM_UNMAP |
| DEV_DELEGATED_SHARED | DEV_SHARED | RMI_DEV_MEM_MAP |
| DEV_SHARED | DEV_DELEGATED_SHARED | RMI_DEV_MEM_UNMAP |
Permitted Granule state transitions are shown in the following figures. Each arc is labeled with the events which can cause the corresponding state transition.
See also:
2.2.3 Granule ownership
A Granule whose state is none of the following is owned by a Realm:
- UNDELEGATED
- DELEGATED
- PDEV
- DEV_UNDELEGATED
- DEV_DELEGATED_PRIVATE
- DEV_DELEGATED_SHARED
The owner of a Granule is identified by the address of a Realm Descriptor (RD).
For a Granule whose state is RD, the ownership relation is recursive: the owning Realm is identified by the address of the RD itself.
A Granule whose state is RTT is one of the following:
A starting level RTT. The address of this RTT is stored in the RD of the owning Realm.
A non-starting level RTT. The address of this RTT is stored in its parent RTT, in an RTT entry whose state is TABLE. Recursively following the parent relationship leads to the RD of the owning Realm.
A Granule whose state is DATA is mapped at a Protected IPA, in an RTT entry whose state is ASSIGNED. The Realm which owns the RTT is the owner of the DATA Granule.
A REC has an “owner” attribute which points to the RD of the owning Realm.
A REC is not mapped at a Protected IPA. Its ownership therefore needs to be recorded explicitly.
A VDEV has an “owner” attribute which points to the RD of the owning Realm.
A VDEV is not mapped at a Protected IPA. Its ownership therefore needs to be recorded explicitly.
See also:
2.2.4 Granule wiping
When the state of a Granule has transitioned from P to DELEGATED and then to any other state, any content associated with P has been wiped.
Any sequence of Granule state transitions which passes through the DELEGATED state causes the Granule contents to be wiped. This is necessary to ensure that information does not leak from one Realm to another, or from a Realm to the Host. Note that no agent can observe the contents of a Granule while its state is DELEGATED.
When the state of a Granule has transitioned from P to DEV_DELEGATED_PRIVATE and then to any other state, any content associated with P has been wiped.
Any sequence of Granule state transitions which passes through the DEV_DELEGATED_PRIVATE state causes the Granule contents to be wiped. This is necessary to ensure that information does not leak from one Realm to another, or from a Realm to the Host. Note that no agent can observe the contents of a Granule while its state is DEV_DELEGATED_PRIVATE.
Wiping is an operation which changes the observable value of a memory location from X to Y, such that the value X cannot be determined from the value Y.
Wiping of a memory location does not reveal, directly or indirectly, any confidential Realm data.
Wiping is not guaranteed to be implemented as zero filling.
Realm software should not assume that the initial contents of uninitialized memory (that is, Realm IPA space which is backed by DATA Granules created using RMI_DATA_CREATE_UNKNOWN) are zero.
See also:
- Arm CCA Security model [4]
- Section 15.3.2
2.3 Realm Execution Context
This section describes the concept of a Realm Execution Context (REC).
2.3.1 Overview
A REC object is an RMM data structure which is used to store the register state of a REC. A Realm Execution Context (REC) is an R-EL0&1 execution context which is associated with a Realm VPE.
A REC object is an RMM data structure which is used to store the register state of a REC.
2.3.2 REC attributes
This section describes the attributes of a REC.
A REC attribute is a property of a REC whose value can be observed or modified either by the Host or by the Realm which owns the REC.
Examples of ways in which a REC attribute may be observable include the outcome of an RMM command, and the PE state following Realm entry.
The attributes of a REC are summarized in the following table.
| Name | Type | Description |
|---|---|---|
| attest_state | RmmRecAttestState | Attestation token generation state |
| attest_challenge | Bits512 | Challenge for under-construction attestation token |
| aux | Address[16] | Addresses of auxiliary Granules |
| emulatable_abort | RmmRecEmulatableAbort | Whether the most recent exit from this REC was due to an Emulatable Data Abort |
| flags | RmmRecFlags | Flags which control REC behavior |
| gprs | Bits64[32] | General-purpose register values |
| mpidr | Bits64 | MPIDR value |
| owner | Address | PA of RD of Realm which owns this REC |
| pc | Bits64 | Program counter value |
| pending | RmmRecPending | Whether a REC operation is pending |
| vdev_id | Bits64 | Virtual device ID |
| inst_id | UInt64 | Device instance ID |
| inst_id_valid | RmmBoolean | Whether device instance ID is valid |
| state | RmmRecState | Lifecycle state |
| sysregs | RmmSystemRegisters | EL1 and EL0 system register values |
| ripas_addr | Address | Next address to be processed in RIPAS change |
| ripas_top | Address | Top address of pending RIPAS change |
| ripas_value | RmmRipas | RIPAS value of pending RIPAS change |
| ripas_destroyed | RmmRipasChangeDestroyed | Whether a RIPAS change from DESTROYED should be permitted |
| ripas_response | RmmRecResponse | Host response to RIPAS change request |
| ripas_dev_pa | Address | Base PA of device memory region, if RIPAS change is pending due to exection of RSI_RDEV_VALIDATE_MAPPING |
| ripas_dev_shared | RmmDevMemShared | Value of shared bit, if RIPAS change is pending due to exection of RSI_RDEV_VALIDATE_MAPPING |
| s2ap_addr | Address | Next address to be processed in S2AP change |
| s2ap_top | Address | Top address of pending S2AP change |
| s2ap_overlay | UInt3 | Overlay index of pending S2AP change |
| s2ap_response | RmmRecResponse | Host response to S2AP change request |
| gic_owner | UInt64 | Index of Plane which is the GIC owner |
The aux attribute of a REC is a list of auxiliary Granules.
The number of auxiliary Granules required for a REC is returned by the RMI_REC_AUX_COUNT command.
Depending on the configuration of the CCA platform and of the Realm, the amount of storage space required for a REC may exceed a single Granule.
The number of auxiliary Granules required for a REC can vary between Realms on a CCA platform.
The number of auxiliary Granules required for a REC is a constant for the lifetime of a given Realm.
The gprs attribute of a REC is the set of general-purpose register values which are saved by the RMM on exit from the REC and restored by the RMM on entry to the REC.
The mpidr attribute of a REC is a value which can be used to identify the VPE associated with the REC.
The pc attribute of a REC is the program counter which is saved by the RMM on exit from the REC and restored by the RMM on entry to the REC.
The runnable flag of a REC determines whether the REC is eligible for execution. The RMI_REC_ENTER command results in a REC entry only if the value of the flag is RUNNABLE.
The runnable flag of a REC is controlled by the Realm. Its initial value is reflected in the Realm Initial Measurement, and during Realm execution its value can be changed by execution of the PSCI_CPU_ON and PSCI_CPU_OFF commands.
The state attribute of a REC is controlled by the Host, by execution of the RMI_REC_ENTER command.
The sysregs attribute of a REC is the set of system register values which are saved by the RMM on exit from the REC and restored by the RMM on entry to the REC.
The gic_owner attribute of a REC is the index of the Plane which is the GIC owner for the REC.
See also:
2.3.3 REC index and MPIDR value
The REC index is the unsigned integer value generated by concatenation of MPIDR fields:
index = Aff3:Aff2:Aff1:Aff0[3:0]
This is illustrated by the following table.
| REC index | Aff3 | Aff2 | Aff1 | Aff0[3:0] |
|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 0 |
| 1 | 0 | 0 | 0 | 1 |
| … | … | … | … | … |
| 16 | 0 | 0 | 1 | 0 |
| … | … | … | … | … |
| 4096 | 0 | 1 | 0 | 0 |
| … | … | … | … | … |
| 1048576 | 1 | 0 | 0 | 0 |
| … | … | … | … | … |
The Aff0[7:4] field of a REC MPIDR value is res0 for compatibility with GICv3.
When creating the nth REC in a Realm, the Host is required to use the MPIDR corresponding to REC index n.
2.3.4 REC lifecycle
2.3.4.1 States
The states of a REC are listed below.
| State | Description |
|---|---|
| REC_READY | REC is not currently running. |
| REC_RUNNING | REC is currently running. |
2.3.4.2 State transitions
Permitted REC state transitions are shown in the following table. The rightmost column lists the events which can cause the corresponding state transition.
A transition from the pseudo-state NULL represents creation of a REC object. A transition to the pseudo-state NULL represents destruction of a REC object.
| From state | To state | Events |
|---|---|---|
| NULL | REC_READY | RMI_REC_CREATE |
| REC_READY | NULL | RMI_REC_DESTROY |
| REC_READY | REC_RUNNING | RMI_REC_ENTER |
| REC_RUNNING | REC_READY | Return from RMI_REC_ENTER |
Permitted REC state transitions are shown in the following figure. Each arc is labeled with the events which can cause the corresponding state transition.
A transition from the pseudo-state NULL represents creation of a REC. A transition to the pseudo-state NULL represents destruction of a REC.
Permitted
The maximum number of RECs per Realm is an implementation defined value which is discoverable via RMI_FEATURES.
See also:
- Section 15.3.6
3 Feature discovery and configuration
This section describes how the Host discovers features which are supported by the RMM implementation, and how the Host configures the features which are used by or available to a Realm.
3.1 Feature discovery and configuration overview
RMM implementations across different CCA platforms may support disparate features and may offer disparate configuration options for Realms.
The features supported by an RMI implementation are discovered by reading feature pseudo-register values using the RMI_FEATURES command.
The term pseudo-register is used because, although these values are stored in memory, their usage model is similar to feature registers specified in the Arm A-profile architecture.
On Realm creation, the Host provides a desired configuration in a Realm parameters structure to the RMI_REALM_CREATE command. The RMM checks that the configuration provided by the Host is supported by the implementation.
Aspects of the Realm configuration which affect the security posture of the Realm are included in the Realm Initial Measurement.
The features supported by an RSI implementation are discovered by reading feature pseudo-register values using the RSI_FEATURES command.
See also:
3.2 Realm hash algorithm
The set of hash algorithms supported by the implementation is reported by the RMI_FEATURES command in RmiFeatureRegister0.
The hash algorithm used by a Realm is provided by the Host when calling RMI_REALM_CREATE.
Providing an unsupported hash algorithm causes execution of RMI_REALM_CREATE to fail.
3.3 Realm LPA2 and IPA width
Support by the implementation for LPA2 is reported by the RMI_FEATURES command in RmiFeatureRegister0.
Usage of LPA2 for Realm Translation Tables is configured by the Host when calling RMI_REALM_CREATE.
Realm IPA width is provided by the Host when calling RMI_REALM_CREATE.
Providing an unsupported IPA width (for example, smaller than the minimum supported, or larger than the maximum supported) causes execution of RMI_REALM_CREATE to fail.
The Host can choose a smaller IPA width than the maximum supported IPA width reported by RMI_FEATURES. This is true regardless of whether LPA2 is enabled for the Realm.
The Host may want to enable LPA2 for a Realm due to either or both of the following reasons:
- to allow the Realm to be configured with a larger IPA width
- to allow access from mappings in the Realm’s stage 2 translation to a larger PA space
A Realm can query its IPA width using the RSI_REALM_CONFIG command.
If LPA2 is not enabled for a Realm then passing a PA greater than or
equal to 2^48 to any of the following commands causes an
error to be returned:
- RMI_DATA_CREATE
- RMI_DATA_CREATE_UNKNOWN
- RMI_RTT_CREATE
- RMI_RTT_AUX_CREATE
- RMI_RTT_MAP_UNPROTECTED
3.4 Realm support for Scalable Vector Extension
Support by the implementation for the Scalable Vector Extension (FEAT_SVE) is reported by the RMI_FEATURES command in RmiFeatureRegister0.
Availability of SVE to a Realm is configured by the Host when calling RMI_REALM_CREATE.
SVE vector length for a Realm is provided by the Host when calling RMI_REALM_CREATE.
Providing a larger-than-supported SVE vector length causes execution of RMI_REALM_CREATE to fail. This is different from the behaviour of the hardware architecture, in which a larger-than-supported SVE vector length value is silently truncated.
The RMI ABI provides a natural mechanism to signal an invalid feature selection, via the return code of RMI_REALM_CREATE. The analog in the hardware architecture would be to generate an illegal exception return, which would cause undesirable coupling between two disparate parts of the architecture, namely the exception model and the SVE feature.
Providing a larger-than-supported SVE vector length causes execution of RMI_REALM_CREATE to fail prepares the architecture for addition of Realm live migration support in future. Assuming that the live migration flow starts with creation of an empty destination Realm, configured identically to the source Realm, this provides a point where the necessary feature support can be checked on the destination platform.
If SVE is supported by the platform but is disabled for the Realm via
the RMI_REALM_CREATE command then a read of
ID_AA64PFR0_EL1.SVE indicates that SVE is not
supported.
The RMM should trap and emulate reads of
ID_AA64PFR0_EL1.SVE.
A Realm should discover SVE support by reading
ID_AA64PFR0_EL1.SVE rather than based on the platform
identity read from MIDR_EL1.
3.5 Realm support for self-hosted debug
Self-hosted debug is always available in Armv8-A.
The number of breakpoints and watchpoints are provided by the Host when calling RMI_REALM_CREATE.
Providing a number of breakpoints which is larger than the number of breakpoints available causes execution of RMI_REALM_CREATE to fail.
Providing a number of watchpoints which is larger than the number of watchpoints available causes execution of RMI_REALM_CREATE to fail.
Specifying that a larger-than-supported number of breakpoints or watchpoints causes execution of RMI_REALM_CREATE to fail prepares the architecture for addition of Realm live migration support in future. Assuming that the live migration flow starts with creation of an empty destination Realm, configured identically to the source Realm, this provides a point where the necessary feature support can be checked on the destination platform.
3.6 Realm support for Performance Monitors Extension
Support by the implementation for the Performance Monitors Extension (FEAT_PMU) is reported by the RMI_FEATURES command in RmiFeatureRegister0.
Availability of PMU to a Realm is configured by the Host when calling RMI_REALM_CREATE.
The number of PMU counters available to a Realm is provided by the Host when calling RMI_REALM_CREATE.
Providing a number of PMU counters which is larger than the number of PMU counters available causes RMI_REALM_CREATE to fail.
Specifying that a larger-than-supported number of PMU counters causes RMI_REALM_CREATE to fail prepares the architecture for addition of Realm live migration support in future. Assuming that the live migration flow starts with creation of an empty destination Realm, configured identically to the source Realm, this provides a point where the necessary feature support can be checked on the destination platform.
3.7 Realm support for Activity Monitors Extension
The Activity Monitors Extension (FEAT_AMUv1) is not available to a Realm.
3.8 Realm support for Statistical Profiling Extension
The Statistical Profiling Extension (FEAT_SPE) is not available to a Realm.
3.9 Realm support for Trace Buffer Extension
The Trace Buffer Extension (FEAT_TRBE) is not available to a Realm.
3.10 Support for Realm device assignment
Support by the implementation for Realm device assignment is reported by the RMI_FEATURES command in RmiFeatureRegister0.
Availability of Realm device assignment for a Realm is configured by the Host when calling RMI_REALM_CREATE.
3.11 Support for auxiliary Planes
The maximum number of auxiliary Planes supported by the implementation is reported by the RMI_FEATURES command in the NUM_AUX_PLANES field of RmiFeatureRegister0.
The maximum number of auxiliary Planes supported by the implementation is either 0 or 3.
The number of auxiliary Planes for a Realm is provided by the Host when calling RMI_REALM_CREATE.
Providing a number of auxiliary Planes which is larger than the maximum number of auxiliary Planes causes RMI_REALM_CREATE to fail.
For a Realm with a non-zero number of auxiliary Planes, the PLANE_RTT field of RmiFeatureRegister0 indicates which one of the following configurations is supported by the implementation:
- The Realm has an RTT tree per Plane
- The Realm has a single RTT tree
- The Realm can be configured to either have an RTT tree per Plane, or a single RTT tree.
Whether a Realm has an RTT tree per Plane is configured by the Host when calling RMI_REALM_CREATE.
3.12 Live Firmware Activation
Live Firmware Activation (LFA) allows an update to a platform firmware component to be activated without rebooting the system. This potentially includes components which are within the TCB of a Realm.
A Realm has an LFA policy which is provided by the Host when calling RMI_REALM_CREATE.
If the LFA policy of a Realm is LFA_DISALLOW then all firmware components within the Realm’s TCB are guaranteed not to be live activated during the lifetime of the Realm.
In order to apply LFA to any firmware component (including the RMM) which is within the TCB of a Realm whose LFA policy is LFA_DISALLOW, the Host must first destroy the Realm.
The mechanism via which the LFA implementation determines whether any Realm with an LFA policy of LFA_DISALLOW currently exists on the system is implementation defined.
If the LFA policy of a Realm is LFA_DISALLOW then the contents of the CCA platform software components claim reflect the state of all firmware components within the Realm’s TCB, throughout the lifetime of the Realm.
The LFA policy of a Realm is reflected in the Realm attestation token.
See also:
- Live Firmware Activation SMC Interface [5]
- Section 7.2.3.2.7
- Section 15.3.25
- Section 15.4.21
3.13 GICv3 virtualization
The number of GICv3 List Registers which can be provided by the Host via the RMI_REC_ENTER command is reported by the RMI_FEATURES command in RmiFeatureRegister0.
Making the number of GICv3 List Registers discoverable via RMI allows the RMM to reserve List Registers for its own usage.
3.14 Support for Realm memory encryption
A Realm A MEC policy describes whether the Realm’s memory encryption context is: A Realm is configured on creation with a MEC policy.
A MEC policy describes whether the Realm’s memory encryption context is:
- Shared with other Realms
- Private to the Realm
4 Realm exception model
This section describes how Realms are executed, and how exceptions which cause exit from a Realm are handled.
See also:
- Section 2.1.2
4.1 Realm exception model overview
A Realm entry is a transfer of control to a Realm.
A Realm exit is a transition of control from a Realm.
When executing in a Realm, an exception taken to R-EL2 or EL3 results in a Realm exit.
A REC entry is a Realm entry due to execution of RMI_REC_ENTER.
The Host provides the address of a REC as an input to the RMI_REC_ENTER command.
In this chapter, both rec and “the target REC” refer to
the REC object which is provided to the RMI_REC_ENTER command.
A RecRun object is a data structure used to pass values between the RMM and the Host on REC entry and on REC exit.
A RecRun object is stored in Non-secure memory.
The Host provides the address of a RecRun object as an input to the RMI_REC_ENTER command.
An implementation is permitted to return RMI_SUCCESS from RMI_REC_ENTER without performing a REC entry. For example, on observing a pending interrupt, the implementation can generate a REC exit due to IRQ without entering the target REC.
A REC exit is return from an execution of RMI_REC_ENTER which caused a REC entry.
The following diagram summarises the possible control flows that result from a Realm exit.
The exception is taken to EL3. The Monitor handles the exception and returns control to the Realm.
The exception is taken to EL3. The Monitor pre-empts Realm Security state and passes control to the Secure Security state. This may be for example due to an FIQ.
The exception is taken to EL2. The RMM decides to perform a REC exit. The RMM executes an SMC instruction, requesting the Monitor to pass control to the Non-secure Security state.
The exception is taken to EL2. The RMM executes an SMC instruction, requesting the Monitor to perform an operation, then returns control to the Realm.
The exception is taken to EL2. The RMM handles the exception and returns control to the Realm.
4.2 REC entry
This section describes REC entry.
4.2.1 RmiRecEnter object
An RmiRecEnter object is a data structure used to pass values from the Host to the RMM on REC entry.
An RmiRecEnter object is stored in the RecRun object which is passed by the Host as an input to the RMI_REC_ENTER command.
On REC entry, execution state is restored from the REC object and from the RmiRecEnter object to the PE.
An RmiRecEnter object contains attributes which are used to manage Realm virtual interrupts.
The attributes of an RmiRecEnter object are summarized in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| flags | 0x0 |
RmiRecEnterFlags | Flags |
| gprs[31] | 0x200 |
Bits64 | Registers |
| gicv3_hcr | 0x300 |
Bits64 | GICv3 Hypervisor Control Register value |
| gicv3_lrs[16] | 0x308 |
Bits64 | GICv3 List Register values |
In this chapter, both rec_enter and “the RmiRecEnter
object” refer to the RmiRecEnter object which is provided to the
RMI_REC_ENTER command.
On REC entry, all rec_enter fields are ignored unless
specified otherwise.
4.2.2 General purpose registers restored on REC entry
On REC entry, if the most recent exit from the target REC was a REC exit due to PSCI, then all of the following occur:
- X0 to X6 contain the PSCI return code and PSCI output values.
- GPR values X7 to X30 are restored from the REC object to the PE.
On REC entry, if either this is the first entry to this REC, or the most recent exit from the target REC was not a REC exit due to PSCI, then GPR values X0 to X30 are restored from the REC object to the PE.
On REC entry, if rec.pending is REC_PENDING_HOST_CALL,
then GPR values X0 to X30 are copied from
rec_enter.gprs[0..30] to the RsiHostCall data
structure.
On REC entry, if writing to the RsiHostCall data structure fails due to the target IPA not being mapped then a REC exit to Data Abort results.
On REC entry, if writing to the RsiHostCall data structure succeeds
then rec.pending is REC_PENDING_NONE.
On REC entry, if RMM access to rec_enter causes a GPF
then the RMI_REC_ENTER command fails with RMI_ERROR_INPUT.
4.2.3 REC entry following REC exit due to Data Abort
On REC entry, if
rec_enter.flags.inject_sea == RMI_INJECT_SEA then the value
of
rec_enter.flags.emul_mmio is ignored.
On REC entry, if the most recent exit from the target REC was a REC
exit due to Emulatable Data Abort and
rec_enter.flags.emul_mmio == RMI_EMULATED_MMIO, then the
return address is the next instruction following the faulting
instruction.
On REC entry, if the most recent exit from the target REC was a REC
exit due to Emulatable Data Abort and the Realm memory access was a read
and rec_enter.flags.emul_mmio == RMI_EMULATED_MMIO, then
the register indicated by ESR_EL2.ISS.SRT is set to
rec_enter.gprs[0].
On execution of RMI_REC_ENTER, if the most recent exit from the
target REC was not a REC exit due to Emulatable Data Abort and
rec_enter.flags.emul_mmio == RMI_EMULATED_MMIO, then the
RMI_REC_ENTER command fails.
On REC entry, if the most recent exit from the target REC was a REC
exit due to Data Abort at an Unprotected IPA and
rec_enter.flags.inject_sea == RMI_INJECT_SEA, then a
Synchronous External Abort is taken to the Realm.
4.3 REC exit
This section describes REC exit.
4.3.1 RmiRecExit object
An RmiRecExit object is a data structure used to pass values from the RMM to the Host on REC exit.
An RmiRecExit object is stored in the RecRun object which is passed by the Host as an input to the RMI_REC_ENTER command.
On REC exit, execution state is saved from the PE to the REC object and to the RmiRecExit object.
An RmiRecExit object contains attributes which are used to manage Realm virtual interrupts and Realm timers.
The attributes of an RmiRecExit object are summarized in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| exit_reason | 0x0 |
RmiRecExitReason | Exit reason |
| flags | 0x8 |
RmiRecExitFlags | Flags |
| esr | 0x100 |
Bits64 | Exception Syndrome Register |
| far | 0x108 |
Bits64 | Fault Address Register |
| hpfar | 0x110 |
Bits64 | Hypervisor IPA Fault Address register |
| rtt_tree | 0x118 |
UInt64 | Index of RTT tree active at time of the exit |
| rtt_level | 0x120 |
Int64 | Level of requested RTT |
| gprs[31] | 0x200 |
Bits64 | Registers |
| gicv3_hcr | 0x300 |
Bits64 | GICv3 Hypervisor Control Register value |
| gicv3_lrs[16] | 0x308 |
Bits64 | GICv3 List Register values |
| gicv3_misr | 0x388 |
Bits64 | GICv3 Maintenance Interrupt State Register value |
| gicv3_vmcr | 0x390 |
Bits64 | GICv3 Virtual Machine Control Register value |
| cntp_ctl | 0x400 |
Bits64 | Counter-timer Physical Timer Control Register value |
| cntp_cval | 0x408 |
Bits64 | Counter-timer Physical Timer CompareValue Register value |
| cntv_ctl | 0x410 |
Bits64 | Counter-timer Virtual Timer Control Register value |
| cntv_cval | 0x418 |
Bits64 | Counter-timer Virtual Timer CompareValue Register value |
| ripas_base | 0x500 |
Bits64 | Base address of target region for pending RIPAS change |
| ripas_top | 0x508 |
Bits64 | Top address of target region for pending RIPAS change |
| ripas_value | 0x510 |
RmiRipas | RIPAS value of pending RIPAS change |
| ripas_dev_pa | 0x518 |
Address | Base PA of device memory region, if RIPAS change is pending due to exection of RSI_RDEV_VALIDATE_MAPPING |
| s2ap_base | 0x520 |
Bits64 | Base address of target region for pending S2AP change |
| s2ap_top | 0x528 |
Bits64 | Top address of target region for pending S2AP change |
| vdev_id | 0x530 |
Bits64 | Virtual device ID |
| imm | 0x600 |
Bits16 | Host call immediate value |
| plane | 0x608 |
UInt64 | Plane index |
| vdev | 0x610 |
Address | VDEV which triggered REC exit due to device communication |
| vdev_action | 0x618 |
RmiVdevAction | Action which triggered REC exit due to device communication |
| pmu_ovf_status | 0x700 |
RmiPmuOverflowStatus | PMU overflow status |
In this chapter, both rec_exit and “the RmiRecExit
object” refer to the RmiRecExit object which is provided to the
RMI_REC_ENTER command.
On REC exit, all rec_exit fields are zero unless
specified otherwise.
4.3.2 Realm exit reason
On return from the RMI_REC_ENTER command, the reason for the REC exit
is indicated by
rec_exit.exit_reason and rec_exit.esr.
See also:
- Section 15.4.3937
4.3.3 General purpose registers saved on REC exit
On REC exit due to PSCI, all of the following are true:
rec_exit.gprs[0]contains the PSCI FID.rec_exit.gprs[1..3]contain the corresponding PSCI arguments. If the PSCI command has fewer than 3 arguments, the remaining values contain zero.- GPR values X7 to X30 are saved from the PE to the REC object.
On REC exit for any reason which is not REC exit due to PSCI, GPR values X0 to X30 are saved from the PE to the REC.
On REC exit for any reason which is neither REC exit due to Host call
nor REC exit due to PSCI, rec_exit.gprs is zero.
On REC exit, if RMM access to rec_exit causes a GPF then
the RMI_REC_ENTER command fails with RMI_ERROR_INPUT.
4.3.4 REC exit due to synchronous exception
A synchronous exception taken to R-EL2 can cause a REC exit.
The following table summarises the behavior of synchronous exceptions taken to R-EL2.
| Exception class | Behavior |
|---|---|
| Trapped WFI or WFE instruction execution | REC exit due to WFI or WFE |
| HVC instruction execution in AArch64 state | Unknown exception taken to Realm |
| SMC instruction execution in AArch64 state | One of:
|
| Trapped MSR, MRS or System instruction execution in AArch64 state | Emulated by RMM, followed by return to Realm |
| Instruction Abort from a lower Exception level | REC exit due to Instruction Abort |
| Data Abort from a lower Exception level | REC exit due to Data Abort |
Realm execution of an SMC which is not part of one of the following ABIs results in a return value of SMCCC_NOT_SUPPORTED:
- PSCI
- RSI
4.3.4.1 REC exit due to WFI or WFE
A REC exit due to WFI or WFE is a REC exit due to WFI, WFIT, WFE or WFET instruction execution in a Realm.
On WFI or WFIT instruction execution in a Realm, a REC exit due to
WFI or WFE is caused if
rec_enter.trap_wfi is RMI_TRAP.
On WFE or WFET instruction execution in a Realm, a REC exit due to
WFI or WFE is caused if
rec_enter.trap_wfe is RMI_TRAP.
On REC exit due to WFI or WFE, all of the following are true:
rec_exit.exit_reasonis RMI_EXIT_SYNC.rec_exit.esr.ECcontains the value ofESR_EL2.ECat the time of the Realm exit.rec_exit.esr.ISS.TIcontains the value ofESR_EL2.ISS.TIat the time of the Realm exit.- All other
rec_exitfields except forrec_exit.givc3_*,rec_exit_cnt*and
rec_exit.pmu_ovf_statusare zero.
On REC exit due to WFI or WFE, if the exit was caused by WFET or WFIT
instruction execution then
rec_exit.gprs[0] contains the timeout value.
4.3.4.2 REC exit due to Instruction Abort
A REC exit due to Instruction Abort is a REC exit due to a Realm instruction fetch from a Protected IPA for which either of the following is true:
- HIPAS is UNASSIGNED and RIPAS is RAM
- RIPAS is DESTROYED
On REC exit due to Instruction Abort, all of the following are true:
rec_exit.exit_reasonis RMI_EXIT_SYNC.rec_exit.esr.ECcontains the value ofESR_EL2.ECat the time of the Realm exit.rec_exit.esr.ISS.SETcontains the value ofESR_EL2.ISS.SETat the time of the Realm exit.rec_exit.esr.ISS.EAcontains the value ofESR_EL2.ISS.EAat the time of the Realm exit.rec_exit.esr.ISS.IFSCcontains the value ofESR_EL2.ISS.IFSCat the time of the Realm exit.rec_exit.hpfarcontains the value ofHPFAR_EL2at the time of the Realm exit.rec_exit.rtt_treecontains the index of the RTT tree within which the contents of an RTTE cause the Realm to exit.- All other
rec_exitfields except forrec_exit.givc3_*,rec_exit_cnt*and
rec_exit.pmu_ovf_statusare zero.
HPFAR_EL2.FIPA does not include the lowest 12 bits of
the faulting IPA. rec_exit.hpfar therefore only reveals the
Realm’s access patterns at a granularity of 4KB. If support was added to
this specification for Granule sizes larger than 4KB,
rec_exit.hpfar would need to be masked accordingly.
4.3.4.3 REC exit due to Data Abort
A REC exit due to Emulatable Data Abort is a REC exit due to a Realm data access to one of the following:
- an Unprotected IPA whose HIPAS is UNASSIGNED_NS, where the access
caused
ESR_EL2.ISS.ISVto be set to'1' - an Unprotected IPA whose HIPAS is ASSIGNED_NS, where the access
caused a stage 2 permission fault and caused
ESR_EL2.ISS.ISVto be set to'1'
A REC exit due to Non-emulatable Data Abort is a REC exit due to a Realm data access to one of the following:
- an Unprotected IPA whose HIPAS is UNASSIGNED_NS, where the access
caused
ESR_EL2.ISS.ISVto be set to'0' - an Unprotected IPA whose HIPAS is ASSIGNED_NS, where the access
caused a stage 2 permission fault and caused
ESR_EL2.ISS.ISVto be set to'0' - a Protected IPA whose HIPAS is UNASSIGNED and whose RIPAS is RAM
- a Protected IPA whose RIPAS is DESTROYED.
On REC exit due to Data Abort, all other rec_exit fields except for of the following are true:
rec_exit.givc3_*exit_reason, rec_exit_cnt* and rec_exit is RMI_EXIT_SYNC.pmu_ovf_status are zero.rec_exit.esr.ILECcontains the value ofESR_EL2.ILECat the time of the Realm exit.rec_exit.esr.ISS.SETcontains the value ofESR_EL2.ISS.SETat the time of the Realm exit.rec_exit.esr.ISS.FnVcontains the value ofESR_EL2.ISS.FnVat the time of the Realm exit.rec_exit.esr.ISS.EAcontains the value ofESR_EL2.ISS.EAat the time of the Realm exit.rec_exit.esr.ISS.DFSCcontains the value ofESR_EL2.ISS.DFSCat the time of the Realm exit.rec_exit.hpfarcontains the value ofHPFAR_EL2at the time of the Realm exit.rec_exit.rtt_treecontains the index of the RTT tree within which the contents of an RTTE cause the Realm to exit.
On REC exit due to Non-emulatableEmulatable Data Abort at an Unprotected IPA, all of the following are true:
rec.emulatable_abortis EMULATABLE_ABORT.rec_exit.esr.ISS.ISVcontains the value ofESR_EL2.ISS.ISVat the time of the Realm exit.rec_exit.esr.ISS.SAScontains the value ofESR_EL2.ISS.SASat the time of the Realm exit.rec_exit.esr.ISS.SFcontains the value ofESR_EL2.ISS.SFat the time of the Realm exit.rec_exit.esr.ISS.WnRcontains the value ofESR_EL2.ISS.WnRat the time of the Realm exit.rec_exit.farcontains the value ofFAR_EL2at the time of the Realm exit, with bits more significant than the size of a Granule masked to zero.
On REC exit due to EmulatableNon-emulatable Data Abort at an Unprotected IPA, all of the following are true:
rec_exit.esr.ILcontains the value ofESR_EL2.ILat the time of the Realm exit.
On REC exit due to Data Abort, all of theother rec_exit fields
except for rec_exit.givc3_*, rec_exit_cnt*
and
rec_exit.pmu_ovf_status are zero.
On REC exit due to Emulatable Data Abort,
ESR_EL2.ISS.SSE is not propagated to the Host. This is
because this field is used to emulate sign extension on loads, which
must be performed by the RMM so that the Realm can rely on
architecturally correct behavior of the virtual execution
environment.
On REC exit due to Emulatable Data Abort, the Host can calculate the
faulting IPA from the rec_exit.hpfar and
rec_exit.far values.
HPFAR_EL2.FIPA does not include the lowest 12 bits of
the faulting IPA. rec_exit.hpfar therefore only reveals the
Realm’s access patterns at a granularity of 4KB. If support was added to
this specification for Granule sizes larger than 4KB,
rec_exit.hpfar would need to be masked accordingly.
On REC exit due to Emulatable Data Abort, if the Realm memory access
was a write,
rec_exit.gprs[0] contains the value of the register
indicated by ESR_EL2.ISS.SRT at the time of the Realm
exit.
On REC exit not due to Emulatable Data Abort,
rec.emulatable_abort is NOT_EMULATABLE_ABORT.
See also:
4.3.5 REC exit due to IRQ
A REC exit due to IRQ is a REC exit due to an IRQ exception which should be handled by the Host.
On REC exit due to IRQ, rec_exit.exit_reason is
RMI_EXIT_IRQ.
On REC exit due to IRQ, rec_exit.esr is zero.
See also:
- Section 6
4.3.6 REC exit due to FIQ
A REC exit due to FIQ is a REC exit due to an FIQ exception which should be handled by the Host.
On REC exit due to FIQ, rec_exit.exit_reason is
RMI_EXIT_FIQ.
On REC exit due to FIQ, rec_exit.esr is zero.
See also:
- Section 6
4.3.7 REC exit due to PSCI
A PSCI function executed by a Realm is either:
- handled by the RMM, returning to the Realm, or
- forwarded by the RMM to the Host via a REC exit due to PSCI.
A REC exit due to PSCI is a REC exit due to Realm PSCI function execution by SMC instruction which was forwarded by the RMM to the Host.
The following table summarises the behavior of PSCI function execution by a Realm.
PSCI functions not listed in this table are not supported. Calling a non-supported PSCI function results in a return value of PSCI_NOT_SUPPORTED.
| PSCI function | Can result in REC exit due to PSCI | Requires Host to call RMI_PSCI_COMPLETE |
|---|---|---|
| PSCI_VERSION | No | - |
| PSCI_FEATURES | No | - |
| PSCI_CPU_SUSPEND | Yes | No |
| PSCI_CPU_OFF | Yes | No |
| PSCI_CPU_ON | Yes | Yes |
| PSCI_AFFINITY_INFO | Yes | Yes |
| PSCI_SYSTEM_OFF | Yes | No |
| PSCI_SYSTEM_RESET | Yes | No |
On REC exit due to PSCI, rec_exit.exit_reason is
RMI_EXIT_PSCI.
On REC exit due to PSCI, rec_exit.gprs contains
sanitised parameters from the PSCI call.
On REC exit due to PSCI, if the command arguments include an MPIDR
value, rec.pending is set to REC_PENDING_PSCI. Otherwise,
rec.pending is set to REC_PENDING_NONE.
Following REC exit due to PSCI, if rec.pending is
REC_PENDING_PSCI, the Host must complete the request by calling the
RMI_PSCI_COMPLETE command, prior to re-entering the REC.
In the call to RMI_PSCI_COMPLETE, the Host provides the target REC, which corresponds to the MPIDR value provided by the Realm. This is necessary because the RMM does not maintain a mapping from MPIDR values to REC addresses. The RMM validates that the REC provided by the Host matches the MPIDR value.
In the call to RMI_PSCI_COMPLETE, the Host provides a PSCI status value, which the RMM handles as follows:
If the Host provides PSCI_SUCCESS, the RMM performs the PSCI operation requested by the Realm. The result of the PSCI operation is recorded in the REC and returned to the Realm on the next entry to the calling REC.
If the Host provides a status value other than PSCI_SUCCESS, the RMM validates that the status code is permitted for the PSCI operation requested by the Realm. If the status code is permitted, it is recorded in the REC and returned to the Realm on the next entry to the calling REC.
4.3.8 REC exit due to RIPAS change pending
A REC exit due to RIPAS change pending is a REC exit due to the Realm issuing a RIPAS change request.
On REC exit due to RIPAS change pending, all of the following are true:
rec_exit.exit_reasonis RMI_EXIT_SYNCRMI_EXIT_RIPAS_CHANGE.rec_exit.ripas_baseis the base address of the region on which a RIPAS change is pending.rec_exit.ripas_topis the top address of the region on which a RIPAS change is pending.rec_exit.ripas_valueis the requested RIPAS value.rec.ripas_addris the base address of the region on which a RIPAS change is pending.rec.ripas_topis the top address of the region on which a RIPAS change is pending.rec.ripas_valueis the requested RIPAS value.
On REC exit due to RIPAS change pending, if the exit was triggered by RSI_RDEV_VALIDATE_MAPPING then all of the following are true:
rec_exit.ripas_dev_pais the base physical address of the device memory region.rec_exit.flags.ripas_dev_sharedis the shared state of the device memory region.rec.ripas_dev_pais the base physical address of the device memory region.rec.ripas_dev_sharedis the shared state of the device memory region.
On REC exit due to RIPAS change pending:
rec_exitholds the base address and the size of the region on which a RIPAS change is pending. These values inform the Host of the bounds of the RIPAS change request.recholds the next address to be processed in a RIPAS change, and the top of the requested RIPAS change region. These values are used by the RMM to enforce that the RMI_RTT_SET_RIPAS command can only apply RIPAS change within the bounds of the RIPAS change request, and to report the progress of the RIPAS change to the Realm on the next REC entry.
On REC exit due to RIPAS change pending, if the exit was triggered by RSI_RDEV_VALIDATE_MAPPING then:
rec_exitholds the base physical address of the device memory region and the shared state of the device memory region. These values allow the Host to create device memory mappings (by calling RMI_DEV_MEM_MAP) on demand.
On REC exit not due to RIPAS change pending, all of the following are true:
rec.ripas_addris 0rec.ripas_topis 0
4.3.9 REC exit due to Host call
A REC exit due to Host call is a REC exit due to RSI_HOST_CALL execution in a Realm.
On REC exit due to Host call, all of the following are true:
rec.pendingis REC_PENDING_HOST_CALL.rec_exit.exit_reasonis RMI_EXIT_HOST_CALL.rec_exit.immcontains the immediate value passed to the RSI_HOST_CALL command.rec_exit.planecontains the index of the Plane which executed the RSI_HOST_CALL command.rec_exit.gprs[0..30]contain the register values passed to the RSI_HOST_CALL command.- All other
rec_exitfields except forrec_exit.givc3_*,rec_exit_cnt*and
rec_exit.pmu_ovf_statusare zero.
4.3.10 REC exit due to SError
A REC exit due to SError is a REC exit due to an SError interrupt during Realm execution.
On REC exit due to SError, all of the following occur:
rec_exit.exit_reasonis RMI_EXIT_SERROR.rec_exit.esr.ECcontains the value ofESR_EL2.ECat the time of the Realm exit.rec_exit.esr.ISS.SETIDScontains the value ofESR_EL2.ISS.SETIDSat the time of the Realm exit.rec_exit.esr.ISS.FnVAETcontains the value ofESR_EL2.ISS.FnVAETat the time of the Realm exit.rec_exit.esr.ISS.EAcontains the value ofESR_EL2.ISS.EAat the time of the Realm exit.rec_exit.esr.ISS.DFSCcontains the value ofESR_EL2.ISS.DFSCat the time of the Realm exit.- All other
rec_exitfields except forrec_exit.hpfargivc3_*contains the value of ,HPFAR_EL2rec_exit_cnt*at the time of the Realm exit. and
rec_exit.rtt_treepmu_ovf_statuscontains the index of the RTT tree within which the contents of an RTTE cause the Realm to exitare zero.
See also:
4.3.11 REC exit due to device communication
A REC exit due to device communication is a REC exit due to RSI_RDEV_CONTINUE execution in a Realm.
On REC exit due to device communication, rec_exit.vdev
identifies the VDEV which triggered the REC exit.
On REC exit due to device communication, the state of the VDEV which triggered the REC exit becomes VDEV_COMMUNICATING.
On REC exit due to device communication, the communication status of the VDEV which triggered the REC exit becomes DEV_COMM_PENDING.
4.3.12 REC exit due to RTT request
A REC exit due to RTT request is a REC exit due to the RMM requiring an RTT to be created in order to proceed with an operation.
On REC exit due to RTT request, rec_exit.rtt_tree
contains the index of the RTT tree within which the contents of an RTTE
cause the Realm to exit.
On REC exit due to RTT request, rec_exit.rtt_level
identifies the level of the requested RTT.
4.3.13 REC exit due to S2AP change pending
A REC exit due to S2AP change pending is a REC exit due to the Realm issuing an S2AP change request.
On REC exit due to S2AP change pending, all of the following are true:
rec_exit.exit_reasonis RMI_EXIT_S2AP_CHANGE.rec_exit.s2ap_baseis the base address of the region on which an S2AP change is pending.rec_exit.s2ap_topis the top address of the region on which an S2AP change is pending.rec.s2ap_addris the base address of the region on which an S2AP change is pending.rec.s2ap_topis the top address of the region on which an S2AP change is pending.rec.s2ap_valueis the requested S2AP value.
On REC exit due to RIPAS change pending:
rec_exitholds the base address and the size of the region on which an S2AP change is pending. These values inform the Host of the bounds of the RIPAS change request.recholds the next address to be processed in an S2AP change, and the top of the requested S2AP change region. These values are used by the RMM to enforce that the RMI_RTT_SET_S2AP command can only apply S2AP change within the bounds of the S2AP change request, and to report the progress of the S2AP change to the Realm on the next REC entry.
On REC exit not due to S2AP change pending, all of the following are true:
rec.s2ap_addris 0rec.s2ap_topis 0
4.3.14 REC exit due to VDEV request
A REC exit due to VDEV request is a REC exit due to the RMM requiring the Host to provide the VDEV object which matches a specified virtual device ID.
On REC exit due to VDEV request, rec_exit.exit_reason is
RMI_EXIT_VDEV_REQUEST.
On REC exit due to VDEV request, rec_exit.vdev_id
contains the requested virtual device ID.
On REC exit due to VDEV request, rec.vdev_pending is set
to REC_PENDING_VDEV_REQUEST.
Following REC exit due to VDEV request, the Host must complete the request by calling the RMI_VDEV_COMPLETE command, prior to re-entering the REC.
In the call to RMI_VDEV_COMPLETE, the Host provides the target VDEV, which corresponds to the virtual device ID value provided by the Realm. This is necessary because the RMM does not maintain a mapping from virtual device IDs to VDEV objects. The RMM validates that the VDEV provided by the Host matches the virtual device ID value.
Following REC exit due to VDEV request, the Host must complete the request by calling the RMI_VDEV_COMPLETE command, prior to re-entering the REC.4.4 Emulated Data Aborts
On REC exit due to Emulatable Data Abort, sufficient information is provided to the Host to enable it to emulate the access, for example to emulate a virtual peripheral.
On taking the REC exit, the Host can either
Establish a mapping in the RTT, in which case it would want the Realm to re-attempt the access. In this case, on the next REC entry the Host sets
enter.flags.emul_mmio = RMI_NOT_EMULATED_MMIO, which indicates that instruction emulation was not performed. This causes the return address to be the faulting instruction.Emulate the access. For an emulated write, the data is provided in
exit.gprs[0]. For an emulated read, the data is provided inenter.gprs[0]. In this case, on the next REC entry the Host sets
enter.flags.emul_mmio = RMI_EMULATED_MMIO, which indicates that the instruction was emulated. This causes the return address to be the address of the instruction which generated the Data Abort plus 4 bytes.
4.5 Host call
This section describes the programming model for Realm communication with the Host.
A Host call is a call made by the Realm to the Host, by execution of the RSI_HOST_CALL command.
A Host call can be used by a Realm to make a hypercall.
On Realm execution of HVC, an Unknown exception is taken to the Realm.
5 Realm memory management
This section describes how Realm memory is managed. This includes:
- How the translation tables which describe the Realm’s address space are managed by the Host.
- Properties of the Realm’s address space, and of the memory which can be mapped into it.
- How faults caused by Realm memory accesses are handled.
5.1 Realm memory management overview
Realm memory management can be viewed from one of two standpoints: the Realm and the Host.
From the Realm’s point of view, the RMM provides security guarantees regarding the IPA space of the Realm and the memory which is mapped into it. These security guarantees are upheld via RSI commands which the Realm can execute in order to query the initial configuration and contents of its address space, and to modify properties of the address space at runtime.
From the Host’s point of view, Realm memory management involves manipulating the stage 2 translation tables which describe the Realm’s address space, and handling faults which are caused by Realm memory accesses. These operations are similar to those involved in managing the memory of a normal VM, but in the case of a Realm they are performed via execution of RMI commands.
5.2 Realm view of memory management
This section describes memory management from the Realm’s point of view.
5.2.1 Realm IPA space
The IPA space of a Realm is divided into two halves: Protected IPA space and Unprotected IPA space.
Software in a Realm should treat the most significant bit of an IPA as a protection attribute.
A Protected IPA is an address in the lower half of a Realm’s
IPA space. The most significant bit of a Protected IPA is
0.
An Unprotected IPA is an address in the upper half of a
Realm’s IPA space. The most significant bit of an Unprotected IPA is
1.
5.2.2 Realm IPA state
A Protected IPA has an associated Realm IPA state (RIPAS).
The RIPAS values are shown in the following table.
| Name | Description |
|---|---|
| DESTROYED | Address which is inaccessible to the Realm due to an action taken by the Host. |
| DEV | Address where memory of an assigned Realm device is mapped. |
| EMPTY | Address where no Realm resources are mapped. |
| RAM | Address where private code or data owned by the Realm is mapped. |
RIPAS values are stored in an RTT.
The Realm can query the RIPAS of an IPA range by executing RSI_IPA_STATE_GET.
5.2.3 Realm access to a Protected IPA
Realm data access to a Protected IPA whose RIPAS is EMPTY causes a Synchronous External Abort taken to the Realm.
Realm instruction fetch from a Protected IPA whose RIPAS is EMPTY causes a Synchronous External Abort taken to the Realm.
Realm data access to a Protected IPA whose RIPAS is RAM does not cause a Synchronous External Abort taken to the Realm.
Realm data access to a Protected IPA whose RIPAS is RAM can cause an REC exit due to Data Abort.
Realm instruction fetch from a Protected IPA whose RIPAS is RAM does not cause a Synchronous External Abort taken to the Realm.
Realm instruction fetch from a Protected IPA whose RIPAS is RAM can cause a REC exit due to Instruction Abort.
Realm data access to a Protected IPA whose RIPAS is DESTROYED causes a REC exit due to Data Abort.
Realm instruction fetch from a Protected IPA whose RIPAS is DESTROYED causes a REC exit due to Instruction Abort.
Realm data access to a Protected IPA whose RIPAS is DEV does not cause a Synchronous External Abort taken to the Realm.
Realm data access to a Protected IPA whose RIPAS is DEV can cause an REC exit due to Data Abort.
Realm instruction fetch from a Protected IPA whose RIPAS is DEV causes a Synchronous External Abort taken to the Realm.
5.2.4 Changes to RIPAS while Realm state is REALM_NEW
This section describes how the RIPAS of a Protected IPA can change while the Realm state is REALM_NEW.
For a Realm in the REALM_NEW state, the RIPAS of a Protected IPA can change to RAM due to Host execution of RMI_DATA_CREATE or RMI_RTT_INIT_RIPAS.
For a Realm in the REALM_NEW state, changing the RIPAS of a Protected IPA to RAM causes the RIM to be updated.
For a Realm in the REALM_NEW state, the RIPAS of a Protected IPA can change to DESTROYED due to Host execution of RMI_DATA_DESTROY or RMI_RTT_DESTROY.
For a Realm in the REALM_NEW state, changing the RIPAS of a Protected IPA to DESTROYED does not cause the RIM to be updated.
5.2.5 Changes to RIPAS while Realm state is REALM_ACTIVE
This section describes how the RIPAS of a Protected IPA can change while the Realm state is REALM_ACTIVE.
A Realm in the REALM_ACTIVE state can request the RIPAS of a region of Protected IPA space to be changed to EMPTY, RAM or DEV.
A Realm in the REALM_ACTIVE state cannot request the RIPAS of a region of Protected IPA space to be changed to DESTROYED.
For a Realm in the REALM_ACTIVE state, the RIPAS of a Protected IPA can change to EMPTY only in response to Realm execution of RSI_IPA_STATE_SET.
The fact that the Host cannot change the RIPAS of a Protected IPA to EMPTY without the Realm having consented to this change prevents the Host from injecting an SEA at a Protected IPA which has been configured to have a RIPAS of RAM, which could potentially trigger unexpected behavior in the Realm.
For a Realm in the REALM_ACTIVE state, the RIPAS of a Protected IPA can change to RAM only in response to Realm execution of RSI_IPA_STATE_SET.
On execution of RSI_IPA_STATE_SET, a Realm can optionally specify that the RIPAS change should only succeed if the current RIPAS is not DESTROYED.
By specifying at step 3 that the RIPAS change should only succeed if the current RIPAS is not DESTROYED, theAn expected pattern for Realm is able to prevent loss of integrity within the initial image IPA range.creation is as follows:
If at step 2, the Host were to execute RMI_DATA_DESTROY on a page within the initial image IPA range, its RIPAS would change to DESTROYED. The Host could then execute RMI_DATA_CREATE_UNKNOWN, with the result that contents of the initial image IPA range no longer match those described by the RIM.Host populates an “initial image” range of Realm IPA space with measured content:
Host executes RMI_DATA_CREATE, establishing a mapping to physical memory, changing RIPAS to RAM and updating the RIM.
Host informs the Realm of the range of IPA space which should be considered by the Realm as DRAM. This is a superset of the IPA range populated in step 1. For unpopulated parts of this IPA range, the RIPAS is EMPTY.
Realm executes RSI_IPA_STATE_SET(ripas=RAM) for the DRAM IPA range described to it in step 2. Following this command, the desired state is:
For the initial image IPA range, the contents match those described by the RIM.
For the entire DRAM IPA range, RIPAS is RAM.
An expected pattern forIf at step 2, the Host were to execute RMI_DATA_DESTROY on a page within the initial image IPA range, its RIPAS would change to DESTROYED. The Host could then execute RMI_DATA_CREATE_UNKNOWN, with the result that contents of the initial image IPA range no longer match those described by the RIM.
By specifying at step 3 that the RIPAS change should only succeed if the current RIPAS is not DESTROYED, the Realm creation is as follows:is able to prevent loss of integrity within the initial image IPA range.
For a Realm in the REALM_ACTIVE state, the RIPAS of a Protected IPA can change to DEV only in response to Realm execution of RSI_RDEV_VALIDATE_MAPPING.
For a Realm in the REALM_ACTIVE state, the RIPAS of a Protected IPA can change to DESTROYED due to Host execution of RMI_DATA_DESTROY or RMI_RTT_DESTROY.
The result of changing the RIPAS of a Protected IPA to DESTROYED is that subsequent Realm accesses to that address do not make forward progress. This is consistent with the principle that the RMM does not provide an availability guarantee to a Realm.
The following diagram summarizes RIPAS changes which can occur when the Realm state is REALM_ACTIVE.
See also:
5.2.6 Realm access to an Unprotected IPA
The RMM does not ensure that the GPT entry of a Granule mapped at an An access by a Realm to an Unprotected IPA permits access via Non-secure PAS. An access by a Realm to an Unprotected IPA can result in a Granule Protection Fault (GPF).
The RMM does not ensure that the GPT entry of a Granule mapped at an Unprotected IPA permits access via Non-secure PAS.
Realm software must be able to handle taking a GPF during access to an Unprotected IPA.
Realm data access to an Unprotected IPA can cause a REC exit due to Data Abort.
On taking a REC exit due to Data Abort at an Unprotected IPA, the Host can inject a Synchronous External Abort to the Realm.
The Host can inject an SEA in response to an unexpected Realm data access to an Unprotected IPA.
Realm data access to an Unprotected IPA which caused
ESR_EL2.ISS.ISV to be set to '1' can be
emulated by the Host.
Realm instruction fetch from an Unprotected IPA causes a Synchronous External Abort taken to the Realm.
5.2.7 Synchronous External Aborts
When a Synchronous External Abort is taken to a Realm,
ESR_EL1.EA == '1'.
5.2.8 Realm access outside IPA space
If stage 1 translation is enabled, Realm access to an IPA which is greater than the IPA space of the Realm causes a stage 1 Address Size Fault taken to the Realm, with the fault status code indicating the level at which the fault occurred.
If stage 1 translation is disabled, Realm access to an IPA which is greater than the IPA space of the Realm causes a stage 1 level 0 Address Size Fault taken to the Realm.
5.2.9 Summary of Realm IPA space properties
The following table summarizes the properties of Realm IPA space.
| Realm IPA | Data access causes abort to Realm? | Data access causes REC exit due to Data Abort? | Instruction fetch causes abort to Realm? | Instruction fetch causes REC exit due to Instruction Abort? |
|---|---|---|---|---|
| Protected, RIPAS=EMPTY | Always (SEA) | Never | Always (SEA) | Never |
| Protected, RIPAS=RAM | Never | When HIPAS=UNASSIGNED | Never | When HIPAS=UNASSIGNED |
| Protected, RIPAS=DEV | Never | When HIPAS=UNASSIGNED | Always (SEA) | Never |
| Protected, RIPAS=DESTROYED | Never | Always | Never | Always |
| Unprotected | Host can inject SEA following REC exit due to Data Abort | When HIPAS=UNASSIGNED_NS | Always (SEA) | Never |
| Outside Realm IPA space | Always (Address Size Fault) | Never | Always (Address Size Fault) | Never |
See also:
- Section 4.2.3
5.2.10 Cache maintenance operations
A data cache invalidate by set / way instruction executed by a Realm either has no effect, or performs a data cache clean and invalidate.
This is to ensure that a Realm cannot invalidate a cache line owned by another Realm.
Arm expects that the RMM will set HCR_EL2.VM == '1',
which causes a data cache invalidate instruction executed at EL1 to
perform a data cache clean and invalidate.
5.3 Host view of memory management
This section describes memory management from the Host’s point of view.
5.3.1 Host IPA state
A Realm IPA has an associated Host IPA state (HIPAS).
The HIPAS values are shown in the following table.
| Name | Description |
|---|---|
| HIPAS_ASSIGNED | Protected IPA which is associated with a DATA Granule. |
| HIPAS_ASSIGNED_DEV_PRIVATE | Protected IPA which is associated with a DEV_PRIVATE Granule. |
| HIPAS_ASSIGNED_DEV_SHARED | Protected IPA which is associated with a DEV_SHARED Granule. |
| HIPAS_ASSIGNED_NS | Unprotected IPA which is associated with an NS Granule. |
| HIPAS_UNASSIGNED | Protected IPA which is not associated with any Granule. |
| HIPAS_UNASSIGNED_NS | Unprotected IPA which is not associated with any Granule. |
HIPAS values are stored in a Realm Translation Table (RTT).
HIPAS transitions are caused by execution of RMI commands.
A mapping at a Protected IPA is valid if the HIPAS is ASSIGNED and the RIPAS is RAM.
A mapping at a Protected IPA is valid if the HIPAS is ASSIGNED_DEV_PRIVATE or ASSIGNED_DEV_SHARED and the RIPAS is DEV.
The following table summarizes, for each combination of RIPAS and HIPAS for a Protected IPA:
- the translation table entry attributes, and
- the behavior which results from Realm access to that IPA.
Each TTD.X column refers to the value of the corresponding “X” field in the architecturally-defined Stage 2 translation table descriptor which is written by the RMM.
| RIPAS | HIPAS | TTD.ADDR | TTD.NS | TTD.VALID | Data access | Instruction fetch |
|---|---|---|---|---|---|---|
| EMPTY | UNASSIGNED | 0 | SEA to Realm | SEA to Realm | ||
| EMPTY | ASSIGNED | DATA | 0 | SEA to Realm | SEA to Realm | |
| EMPTY | ASSIGNED_DEV_* | DEV | 0 | SEA to Realm | SEA to Realm | |
| RAM | UNASSIGNED | 0 | REC exit due to Data Abort | REC exit due to Instruction Abort | ||
| RAM | ASSIGNED | DATA | 0 | 1 | Data access | Instruction fetch |
| RAM | ASSIGNED_DEV_* | DEV | 0 | REC exit due to Data Abort | REC exit due to Instruction Abort | |
| DESTROYED | UNASSIGNED | 0 | REC exit due to Data Abort | REC exit due to Instruction Abort | ||
| DESTROYED | ASSIGNED | DATA | 0 | REC exit due to Data Abort | REC exit due to Instruction Abort | |
| DESTROYED | ASSIGNED_DEV_* | DEV | 0 | REC exit due to Data Abort | REC exit due to Instruction Abort | |
| DEV | UNASSIGNED | 0 | REC exit due to Data Abort | SEA to Realm | ||
| DEV | ASSIGNED | DATA | 0 | REC exit due to Data Abort | SEA to Realm | |
| DEV | ASSIGNED_DEV_* | DEV | 1 D | eviceDevice access S | EASEA to Realm |
5.3.2 Changes to HIPAS while Realm state is REALM_NEW
This section describes how the HIPAS of a Protected IPA can change while the Realm state is REALM_NEW.
The following diagram summarizes HIPAS changes at a Protected IPA which can occur when the Realm state is REALM_NEW.
See also:
5.3.3 Changes to HIPAS while Realm state is REALM_ACTIVE
This section describes how the HIPAS of a Protected IPA can change while the Realm state is REALM_ACTIVE.
The following diagram summarizes HIPAS changes at a Protected IPA which can occur when the Realm state is REALM_ACTIVE.
5.3.4 Summary of changes to HIPAS and RIPAS of a Protected IPA
The following diagram summarizes HIPAS and RIPAS changes at a Protected IPA which can occur when the Realm state is NEW.
Transitions due to execution of RMI_RTT_DESTROY are omitted from the diagram. Execution of this command results in a transition to HIPAS=UNASSIGNED, RIPAS=DESTROYED.
The following diagram summarizes HIPAS and RIPAS changes at a Protected IPA which can occur when the Realm state is REALM_ACTIVE.
Transitions due to execution of RMI_RTT_DESTROY are omitted from the diagram. Execution of this command results in a transition to HIPAS=UNASSIGNED, RIPAS=DESTROYED.
See also:
5.3.5 Dependency of RMI command execution on RIPAS and HIPAS values
The following table summarizes dependencies on RMI command execution on the current Protected IPA.
| Command | Dependency on RIPAS | Dependency on HIPAS | New RIPAS | New HIPAS |
|---|---|---|---|---|
| RMI_DATA_CREATE | None | HIPAS is UNASSIGNED | RAM | ASSIGNED |
| RMI_DATA_CREATE_UNKNOWN | None | HIPAS is UNASSIGNED | Unchanged | ASSIGNED |
| RMI_DATA_DESTROY | If RIPAS is not RAM | HIPAS is ASSIGNED | Unchanged | UNASSIGNED |
| RMI_DATA_DESTROY | If RIPAS is RAM | HIPAS is ASSIGNED | DESTROYED | UNASSIGNED |
| RMI_RTT_CREATE | None | None | Unchanged | Unchanged |
| RMI_RTT_DESTROY | None | HIPAS of all entries is UNASSIGNED | DESTROYED | Unchanged |
| RMI_RTT_FOLD | RIPAS of all entries is identical | HIPAS of all entries is identical | Unchanged | Unchanged |
| RMI_RTT_INIT_RIPAS | RIPAS is EMPTYNone | HIPAS is UNASSIGNED | RAM | Unchanged |
| RMI_RTT_SET_RIPAS | Optionally, Realm may specify that RIPAS is not DESTROYED | None | As specified by Realm | Unchanged |
| RMI_DEV_MEM_MAP | None | HIPAS is UNASSIGNED | Unchanged | ASSIGNED_DEV_* |
| RMI_DEV_MEM_UNMAP | If RIPAS is not DEV | HIPAS is ASSIGNED_DEV_* | Unchanged | UNASSIGNED |
| RMI_DEV_MEM_UNMAP | If RIPAS is DEV | HIPAS is ASSIGNED_DEV_* | DESTROYED | UNASSIGNED |
The following table summarizes dependencies on RMI commandSuccessful execution on the current Protected of RMI_DATA_CREATE_UNKNOWN does not depend on the RIPAS value of the target IPA.
Successful execution of RMI_DATA_CREATE_UNKNOWNRMI_DATA_DESTROY does not depend on the RIPAS value of the target IPA.
Successful execution of RMI_DATA_DESTROYRMI_RTT_DESTROY does not depend on the RIPAS values of entries in the target RTT.
Successful execution of RMI_RTT_FOLD does depend on the RIPAS values of entries in the target RTT.
Successful execution of RMI_DEV_MEM_UNMAP does not depend on the RIPAS value of the target IPA.
See also:
5.3.6 Changes to HIPAS of an Unprotected IPA
The following diagram summarises HIPAS transitions for an Unprotected IPA.
See also:
5.4 RIPAS change
A RIPAS change is a process via which the RIPAS of a region of Protected IPA space is changed, for a Realm whose state is REALM_ACTIVE.
A RIPAS change consists of actions taken first by the Realm, and then by the Host:
- The Realm issues a RIPAS change request by executing
RSI_IPA_STATE_SET or RSI_RDEV_VALIDATE_MAPPING.
- The input values to RSI_IPA_STATE_SET include:
- The requested IPA range:
[base, top of the) - The requested RIPAS value (either EMPTY or RAM)
- A flag which indicates whether a change from DESTROYED should be permitted
- The requested IPA range:
- For RSI_RDEV_VALIDATE_MAPPING:
- The input values include the requested IPA range:
[base, top) - The requested RIPAS value is implicitly DEV
- A change from DESTROYED is implicitly not permitted
- The input values include the requested IPA range:
- The RMM records these values in the REC, and then performs a REC exit due to RIPAS change pending.
- The input values to RSI_IPA_STATE_SET include:
- In response, the Host executes zero or more RMI_RTT_SET_RIPAS commands.
- If the requested RIPAS value was not EMPTY then at the next RMI_REC_ENTER the Host can optionally indicate that it rejects the RIPAS change request.
Output values from RSI_IPA_STATE_SET or RSI_RDEV_VALIDATE_MAPPING indicate:
- The top of the IPA range which has been modified by the command
(
new_base). - If the requested RIPAS value was not EMPTY, whether the Host rejected the Realm request.
Output values from RSI_IPA_STATE_SET or RSI_RDEV_VALIDATE_MAPPING are expected to be handled by the Realm as follows:
new_base |
response |
Meaning | Expected Realm action |
|---|---|---|---|
new_base == base |
RSI_ACCEPT | RIPAS change incomplete. | Call the command again, with base = new_base. |
base < new_base < top |
RSI_ACCEPT | RIPAS change incomplete. | Call the command again, with base = new_base. |
new_base == top |
RSI_ACCEPT | RIPAS change complete. | No further Realm action required. |
new_base == base |
RSI_REJECT | RIPAS change request rejected. | Depends on protocol agreed between Realm and Host, out of scope of this specification. |
base < new_base < top |
RSI_REJECT | RIPAS change to partial region Host rejected request to change RIPAS for region
|
Depends on protocol agreed between Realm and Host, out of scope of this specification. |
The RIPAS change process, together with the Realm Initial Measurement ensures that a Realm can always reliably determine the RIPAS of any Protected IPA.
A RIPAS change is applied by one or more calls to the RMI_RTT_SET_RIPAS command.
Successful execution of RMI_RTT_SET_RIPAS targets an RTTE at address
rec.ripas_addr.
On successful execution of RMI_RTT_SET_RIPAS, both of the following are set to the address of the next page whose RIPAS is to be modified:
rec.ripas_addr- The command output value
If both of the following are true on successful execution of RMI_RTT_SET_RIPAS
- The RIPAS change request indicated that a change from DESTROYED should not be permitted
- A page P within the target IPA range has RIPAS value DESTROYED
then rec.ripas_addr and the command output value are
both set to P.
On REC entry following a REC exit due to RIPAS change, GPR values are updated to indicate for how much of the target IPA range the RIPAS change has been applied.
To complete a RIPAS change for a given target IPA range, a Realm should execute RSI_IPA_STATE_SET or RSI_RDEV_VALIDATE_MAPPING in a loop, until the value of X1 reaches the top of the target IPA range.
On REC entry following a REC exit due to RIPAS change,
rec.ripas_response is set to the value of
enter.flags.ripas_response.
Otherwise,If all of the following are true then the output value of RSI_IPA_STATE_SET or RSI_RDEV_VALIDATE_MAPPING indicates “Host accepted the request”.rejected the request”:
rec.ripas_valueis RAM.rec.ripas_addris not equal torec.ripas_top.rec.ripas_responseis REJECT.
If all of the following are true thenOtherwise, the output value of RSI_IPA_STATE_SET or RSI_RDEV_VALIDATE_MAPPING indicates “Host rejected the request”:accepted the request”.
Receipt of a rejection for a RIPAS change request whose parameters were valid is expected to be fatal for the Realm.
See also:
5.5 Realm Translation Table
This section introduces the stage 2 translation table used by a Realm.
5.5.1 RTT overview
A Realm Translation Table (RTT) is an abstraction over an Armv8-A stage 2 translation table used by a Realm.
The attributes and format of an Armv8-A stage 2 translation table are defined by the Armv8-A Virtual Memory System Architecture (VMSA) Arm Architecture Reference Manual for A-Profile architecture [3].
The translation granule size of an RTT is 4KB.
The RMM architecture can only be deployed on a hardware platform which implements a translation granule size of 4KB.
The contents of an RTT are not directly accessible to the Host.
The contents of an RTT are manipulated using RMM commands. These commands allow the Host to manipulate the contents of the RTT used by a Realm, subject to constraints imposed by the RMM.
An RTT entry (RTTE) is an abstraction over an Armv8-A stage 2 translation table descriptor.
An RTTE contains an output address which can point to one of the following:
- Another RTT
- A DATA Granule which is owned by the Realm
- Non-secure memory which is accessible to both the Realm and the Host
5.5.2 RTT structure and configuration
An RTT tree is a hierarchical data structure composed of RTTs, connected via Table Descriptors.
An RTT contains an array of RTTEs.
An RTT level is the depth of an RTT within an RTT tree.
An RTT does not have an intrinsic “level” attribute. The level of an RTT is determined by its position within an RTT tree.
The RTT level of the root of an RTT tree is called the starting level.
The maximum depth of an RTT tree depends on all of the following:
- whether LPA2 is selected when the Realm is created
- the rtt_level_start attribute of the Realm
- the ipa_width attribute of the Realm.
5.5.3 RTT starting level
The RTT starting level is set when a Realm is created.
The number of starting level RTTs is architecturally defined as a function of the Realm IPA width and the RTT starting level. See Arm Architecture Reference Manual for A-Profile architecture [3] for further details.
The address of the first starting level RTT is stored in the RTT base attribute of the owning Realm.
The RTT base attribute is set when a Realm is created.
See also:
- Section 2.1.3
5.5.4 RTT entry
An RTT entry (RTTE) is an abstraction over an Armv8-A stage 2 translation table descriptor. The attributes and format of an Armv8-A stage 2 translation table descriptor are defined by the Armv8-A Virtual Memory System Architecture (VMSA) Arm Architecture Reference Manual for A-Profile architecture [3].
An RTTE has a state.
The RTTE state values are shown in the following table.
| Name | Description |
|---|---|
| ASSIGNED | This RTTE is identified by a Protected IPA. The output address of this RTTE points to a DATA Granule. |
| ASSIGNED_DEV_PRIVATE | This RTTE is identified by a Protected IPA. The output address of this RTTE points to a DEV_PRIVATE Granule. |
| ASSIGNED_DEV_SHARED | This RTTE is identified by a Protected IPA. The output address of this RTTE points to a DEV_SHARED Granule. |
| ASSIGNED_NS | This RTTE is identified by an Unprotected IPA. The output address of this RTTE points to an NS Granule. |
| AUX_DESTROYED | An auxiliary RTT was destroyed while a corresponding primary RTT entry was live. |
| TABLE | The output address of this RTTE points to the next-level RTT. |
| UNASSIGNED | This RTTE is identified by a Protected IPA. This RTTE is not associated with any Granule. |
| UNASSIGNED_NS | This RTTE is identified by an Unprotected IPA. This RTTE is not associated with any Granule. |
The state of an RTTE in a RTT which is not level 1 or level 2 or level 3 is UNASSIGNED, UNASSIGNED_NS or TABLE.
The output address of an RTTE whose state is TABLE and which is in a level n RTT is the physical address of a level n+1 RTT.
An RTT whose level n is not the starting RTT level is pointed-to by exactly one TABLE RTTE in a level n-1 RTT.
The following diagram shows an example RTT tree, annotated with RTTE states.
The function AddrIsRttLevelAligned() is used to evaluate
whether an address is aligned to the address range described by an RTTE
at a specified RTT level.
5.5.5 RTT reading
Attributes of an RTTE, including the RTTE state, can be read by calling the RMI_RTT_READ_ENTRY command. The set of RTTE attributes which are returned depends on the state of the RTTE.
See also:
- Section 15.3.43
5.5.6 RTT folding
An RTT is homogeneous if its entries satisfy one of the conditions in the following table. If an RTT is homogeneous, the following table specifies the state to which the parent RTTE is set.
| Conditions on child RTT contents | Parent RTTE state |
|---|---|
All of the following are true:
|
UNASSIGNED |
| State of all entries is UNASSIGNED_NS | UNASSIGNED_NS |
All of the following are true:
|
ASSIGNED |
All of the following are true:
|
ASSIGNED_NS |
All of the following are true:
|
ASSIGNED_DEV_PRIVATE |
All of the following are true:
|
ASSIGNED_DEV_SHARED |
The function RttIsHomogeneous() is used to evaluate
whether an RTT is homogeneous.
RTT folding is the operation of destroying a homogeneous child RTT, and moving information which was stored in the child RTT into the parent RTTE.
On RTT folding, the state of the parent RTTE is determined from the contents of the child RTTEs.
The function RttFold() is used to evaluate the parent
RTTE state which results from an RTT folding operation.
On RTT folding, if the state of the parent RTTE is any of the following then the attributes of the parent RTTE are copied from the child RTTEs:
- ASSIGNED
- ASSIGNED_NS
- ASSIGNED_DEV_PRIVATE
- ASSIGNED_DEV_SHARED
5.5.7 RTT unfolding
RTT unfolding is the operation of creating a child RTT, and populating it based on the contents of the parent RTTE.
On RTT unfolding, the state of all RTTEs in the child RTT are set to the state of the parent RTTE.
On RTT unfolding, if the state of the parent RTTE is any of the following then the output addresses of RTTEs in the child RTT are set to a contiguous range which starts from the address of the parent RTTE:
- ASSIGNED
- ASSIGNED_NS
- ASSIGNED_DEV_PRIVATE
- ASSIGNED_DEV_SHARED
See also:
- Section 15.3.38
5.5.8 RTTE liveness and RTT liveness
RTTE liveness is a property which means that a physical address is stored in the RTTE.
An RTTE is live if the RTTE state is any of the following:
- ASSIGNED
- ASSIGNED_NS
- ASSIGNED_DEV_PRIVATE
- ASSIGNED_DEV_SHARED
- TABLE
The function RttSkipNonLiveEntries() is used to scan an
RTT to find the next live RTTE. The resulting IPA is returned to the
Host from commands whose successful execution causes a live RTTE to
become non-live.
Identifying the next live RTTE allows the Host to avoid calls to RMI_RTT_READ_ENTRY when unmapping ranges of a Realm’s IPA space, for example during Realm destruction.
RTT liveness is a property which means that there exists another RMM data structure which is referenced by the RTT.
An RTT is live if, for any of its entries, the RTTE state is any of the following:
- ASSIGNED
- ASSIGNED_DEV_PRIVATE
- ASSIGNED_DEV_SHARED
- TABLE
Note that an RTT can be non-live, even if one of its entries is live. This would be the case for example if the RTT corresponds to an Unprotected IPA range and the state of one of its entries is ASSIGNED_NS.
The function RttIsLive() is used to evaluate whether an
RTT is live.
See also:
5.5.9 RTT destruction
RTT destruction is the operation of destroying a child RTT, and discarding information which was stored in the child RTT.
An RTT cannot be destroyed if it is live.
An RTT can be destroyed regardless of whether it is homogeneous.
Following RTT destruction, all of the following are true for the parent RTTE:
- RIPAS is DESTROYED
- RTTE state is UNASSIGNED
5.5.10 RTT walk
An IPA is translated to a PA by walking an RTT tree, starting at the RTT base.
The behaviour of an RTT walk is defined by the Armv8-A Virtual Memory System Architecture (VMSA) Arm Architecture Reference Manual for A-Profile architecture [3].
The inputs to an RTT walk are:
- a Realm Descriptor, which contains the address of the initial RTT
- an RTT tree index
- a target IPA
- a target RTT level.
The RTT walk terminates when either:
- it reaches the target RTT level, or
- it reaches an RTTE whose state is not TABLE.
The result of an RTT walk performed by the RMM is a data structure of type RmmRttWalkResult.
The attributes of an RmmRttWalkResult are summarized in
the following table.
| Name | Type | Description |
|---|---|---|
| level | Int8 | RTT level reached by the walk |
| rtt_addr | Address | Address of RTT reached by the walk |
| rtte | RmmRttEntry | RTTE reached by the walk |
The function RmmRttWalkResult RttWalk(rd, addr, level)
is used to represent an RTT walk.
The input address to an RTT walk is always less than
2^w, where w is the IPA width of the target
Realm.
See also:
5.5.11 RTT entry attributes
5.5.11.1 RTT entry attributes for ASSIGNED mappings
The cacheability attributes of an RTT entry whose state is ASSIGNED are independent of any stage 1 descriptors and of the state of the stage 1 MMU.
The RMM uses FEAT_S2FWB to ensure that the cacheability attributes of an RTT entry whose state is ASSIGNED are independent of stage 1 translation.
The attributes of an RTT entry whose state is ASSIGNED include the following:
- Normal memory
- Inner Write-Back Cacheable
- Inner Shareable
5.5.11.2 RTT entry attributes for ASSIGNED_DEV mappings
The cacheability attributes of an RTT entry whose state is ASSIGNED_DEV_PRIVATE or ASSIGNED_DEV_SHARED are determined by the stage 1 descriptors.
In an RTT entry whose state is ASSIGNED_DEV_PRIVATE or
ASSIGNED_DEV_SHARED, MemAttr is set to
0b111.
In an RTT entry whose state is ASSIGNED_DEV_PRIVATE or
ASSIGNED_DEV_SHARED, S2AP is set to RW.
See also:
5.5.11.3 RTT entry attributes for ASSIGNED_NS mappings
The following attributes of an RTT entry whose state is ASSIGNED_NS are Host-controlled Unprotected RTT attributes:
ADDRMemAttr[2:0]S2AP
In an RTT entry whose state is ASSIGNED_NS, MemAttr[3]
is res0 because the RMM uses
FEAT_S2FWB.
In an RTT entry whose state is ASSIGNED_NS, the shareability attributes are as follows:
- Inner Shareable if the mapping is cacheable.
- Outer Shareable if the mapping is non-cacheable.
The shareability attributes of an RTT entry which corresponds to an Unprotected IPA are expected to be controlled by the RMM as follows:
- If LPA2 is enabled at stage 2 then the RMM is expected to set
VTCR_EL2.DS == '1'. - If LPA2 is not enabled at stage 2 then the RMM is expected to set
the value of the
SHfield in the translation table descriptor based on the value of theMemAttrfield.
See also:
5.5.11.4 Hardware access flag and dirty bit management
Hardware access flag and dirty bit management is disabled for the stage 2 translation used by a Realm.
Hardware access flag and dirty bit management may be enabled by software executing within the Realm, for its own stage 1 translation.
6 Realm interrupts and timers
This specification requires that a virtual Generic Interrupt Controller (vGIC) is presented to a Realm. This vGIC should be architecturally compliant with respect to GICv3 with no legacy operation.
The Host is able to inject virtual interrupts using the GIC virtual CPU interface.
The vGIC presented to a Realm is expected to be implemented via a combination of Host emulation and RMM mediation, as follows:
Management of Non-secure physical interrupts is performed by the Host, via the GIC Interrupt Routing Infrastructure (IRI).
The Host is responsible for emulating a GICv3 distributor MMIO interface.
The Host is responsible for emulating a GICv3 redistributor MMIO interface for each REC.
The GIC MMIO interfaces emulated by the Host must be presented to the Realm via its Unprotected IPA space.
The Host may optionally provide a virtual Interrupt Translation Service (ITS). The Realm must allocate ITS tables within its Unprotected IPA space.
The RMM allows the Host to control some of the GIC virtual CPU interface state which is observed by the Realm. This state is designed to be the minimum required to allow the Host to correctly manage interrupts for the Realm, with integrity guaranteed by the RMM for the remainder of the GIC CPU interface state.
On REC exit, the RMM exposes some of the GIC virtual CPU interface state to the Host. This state is designed to be the minimum required to allow the Host to correctly manage interrupts for the Realm, with confidentiality guaranteed by the RMM for the remainder of the GIC virtual CPU interface state.
On every REC exit, the EL1 timer state is exposed to the Host. The RMM guarantees that a REC exit occurs whenever a Realm EL1 timer asserts or de-asserts its output.
See also:
6.1 Realm interrupts
This section describes the programming model for a REC’s GIC CPU interface.
The value of enter.gicv3_lrs[n] is valid if all of the
following are true:
- The value is an architecturally valid encoding of
ICH_LR<n>_EL2according to Arm Generic Interrupt Controller (GIC) Architecture Specification version 3 and version 4 [6]. HW == '0'.
The GICv3 architecture states that, if HW == '1' then
the virtual interrupt must be linked to a physical interrupt whose state
is Active, otherwise behavior is undefined. The RMM is unable to
validate that invariant, so it imposes the constraint that
HW == '0'.
The value of enter.gicv3_hcr is valid if the value is an
architecturally valid encoding of ICH_HCR_EL2 according to
Arm Generic Interrupt Controller (GIC)
Architecture Specification version 3 and version 4
[6].
REC entry fails if the value of any enter.gicv3_*
attribute is invalid.
On REC entry, ICH_LR<n>_EL2 is set to
enter.gicv3_lrs[n], for all values of n
supported by the PE.
On REC entry, the following fields in ICH_HCR_EL2 are
set to the corresponding values in enter.gicv3_hcr:
UIELRENPIENPIEVGrp0EIEVGrp0DIEVGrp1EIEVGrp1DIETDIR
If any other fieldOn REC entry, fields in enter.gicv3_hcr ismust be set to ‘1’,
then RMI_REC_ENTER fails.
‘0’ except for the following:
UIELRENPIENPIEVGrp0EIEVGrp0DIEVGrp1EIEVGrp1DIETDIR
On REC entry, fieldsIf any other field in enter.gicv3_hcr must beis set to
‘0’ except for the following: ‘1’,
then RMI_REC_ENTER fails.
The RMM provides access to the GIC virtual CPU interface to the Realm
and therefore controls the enable bit and most trap bits in
ICH_HCR_EL2. The maintenance interrupt control bits are
controlled by the Host, because the maintenance interrupts are provided
as hints to the hypervisor to allocate List Registers optimally and to
correctly emulate GICv3 behavior. The TDIR bit is also
controlled by the Host because it is used when supporting
EOImode == '1' in the Realm. This mode is used to allow
deactivation of virtual interrupts across RECs. This deactivation must
be handled by the Host because the RMM can only operate on a single REC
during execution of RMI_REC_ENTER.
A REC exit due to IRQ is not generated for an interrupt which is
masked by the value of ICC_PMR_EL1 at the time of REC
entry.
The RMM should preserve the value of ICC_PMR_EL1 during
REC entry.
On REC exit, exit.gicv3_vmcr contains the value of
ICH_VMCR_EL2 at the time of the Realm exit.
On REC exit, exit.gicv3_misr contains the value of
ICH_MISR_EL2 at the time of the Realm exit.
The Host could in principle infer the value of
ICH_MISR_EL2 at the time of the Realm exit from the
combination of exit.gicv3_lrs[n] and
exit.gicv3_hcr. However, this would be cumbersome,
error-prone, and diverge from the design of existing hypervisor
software.
On REC exit, exit.gicv3_lrs[n] contains the value of
ICH_LR<n>_EL2 at the time of the Realm exit, for all
values of n supported by the PE.
All otherOn REC exit, the following fields contain zeroin exit.gicv3_hcr
contains the value of the corresponding field in
ICH_HCR_EL2 at the time of the Realm exit:
EOIcountUIELRENPIENPIEVGrp0EIEVGrp0DIEVGrp1EIEVGrp1DIETDIR
On REC exit, the followingAll other fields in exitcontain zero.gicv3_hcr contains the value of the corresponding field in ICH_HCR_EL2 at the time of the Realm exit:
On REC exit, the values of the following registers may have changed:
ICH_AP0R<n>_EL2ICH_AP1R<n>_EL2ICH_LR<n>_EL2ICH_VMCR_EL2ICH_HCR_EL2
It is the responsibility of the caller to save and restore GIC virtualization system control registers if their value needs to be preserved following execution of RMI_REC_ENTER.
On REC entry, the values of the GIC virtualization control system registers are overwritten. The Non-secure hypervisor runs at EL2 and therefore does not make direct use of the virtual GIC CPU interface for its own execution. This means that saving / restoring the caller’s GIC virtualization control system registers would typically not be required and would add additional runtime overhead for each execution of RMI_REC_ENTER.
On REC exit, ICH_HCR_EL2.En == '0'.
Disabling the virtual GIC CPU interface ensures that the caller does not receive unexpected GIC maintenance interrupts. A stronger constraint, for example stating that all GIC virtualization control system registers are zero on REC exit, was considered. However, this was rejected on the basis that it may preclude future optimisations, such as returning early from execution of RMI_REC_ENTER, without needing to first write zero to all GIC virtualization control system registers, if an interrupt is pending.
See also:
6.2 Realm timers
This section describes the operation of architectural timers during Realm execution, including the following:
- The behavior of EL2 timers programmed by the Host
- The behavior of EL1 timers as perceived by the Realm
- The Realm timer state which is exposed to the Host on REC exit, in order to facilitate virtualization of timer interrupts
Architectural timers are available to a Realm and behave according to their architectural specification.
If the Host has programmed an EL1 timer to assert its output during Realm execution, that timer output is not guaranteed to assert.
If the Host has programmed an EL2 timer to assert its output during Realm execution, that timer output is guaranteed to assert.
Both the virtual and physical counter values are guaranteed to be monotonically increasing when read by a Realm, in accordance with the architectural counter behavior.
A read by a Realm of either the virtual or physical counter at the same place in the instruction flow would return the same value.
In order to ensure that the Realm has a consistent view of time, the virtual timer offset must be fixed for the lifetime of the Realm. The absolute value of the virtual timer offset is not important, so the value zero has been chosen for simplicity of both the specification and the implementation.
The rule that virtual and physical counter values are identical may need to be amended if a future version of the specification supports migration and / or virtualization of time based on the virtual counter differing from the physical counter.
On a change in the output of an EL1 timer which requires a Realm-observable change to the state of virtual interrupts, a REC exit occurs.
On REC exit, Realm EL1 timer state is exposed via the RmiRecExit object:
exit.cntv_ctlcontains the value ofCNTV_CTL_EL0at the time of the Realm exit.exit.cntv_cvalcontains the value ofCNTV_CVAL_EL0at the time of the Realm exit, expressed as if the virtual counter offset was zero.exit.cntp_ctlcontains the value ofCNTP_CTL_EL0at the time of the Realm exit.exit.cntp_cvalcontains the value ofCNTP_CVAL_EL0at the time of the Realm exit, expressed as if the physical counter offset was zero.
The Host should check the Realm EL1 timer state on every return from
RMI_REC_ENTER and update virtual interrupt state accordingly. This is
true regardless of the value of exit.exit_reason: even if
the return occurred for a reason unrelated to timers (for example, a REC
exit due to Data Abort), the Realm EL1 timer state should be
checked.
On REC entry, for both the EL1 Virtual Timer and the EL1 Physical Timer, if the EL1 timer asserts its output in the state described in the REC exit structure from the previous REC exit then the RMM masks the hardware timer signal before returning to the Realm.
This masking is done to allow the Realm to make forward progress, which would otherwise be prevented by the hardware timer generating a physical interrupt that would cause a Realm exit.
During Realm execution, when the hardware timer signal is masked, the Realm may write to the timer registers, causing the hardware timer to become de-asserted and possibly asserted again. Such changes in the output of the EL1 timer are not required to result in a REC exit if the RMM can infer that the change should not result in a Realm-observable change to the state of virtual interrupts.
It is only when a change in the hardware timer output means that the corresponding virtual interrupt needs to be made pending or idle, that a REC exit must occur.
During Realm execution, when the hardware timer signal is masked, the Realm may write to the timer registers, causing the hardware timer to become de-asserted and possibly asserted again. Such changes in the output of the EL1 timer are not required to result in a REC exit if the RMM can infer that the change should not result in a Realm-observable change to the state of virtual interrupts. This masking is done to allow the Realm to make forward progress, which would otherwise be prevented by the hardware timer generating a physical interrupt that would cause a Realm exit. On REC entry, for both the EL1 Virtual Timer and the EL1 Physical Timer, if the EL1 timer asserts its output in the state described in the REC exit structure from the previous REC exit then the RMM masks the hardware timer signal before returning to the Realm.7 Realm measurement and attestation
This section describes how the initial state of a Realm is measured and can be attested.
7.1 Realm measurements
This section describes how Realm measurement values are calculated.
A Realm measurement value is a rolling hash.
A Realm Hash Algorithm (RHA) is an algorithm which is used to extend a Realm measurement value.
The RHA used by a Realm is selected via the hash_algo
attribute.
7.1.1 Realm Initial Measurement
This section describes how the Realm Initial Measurement (RIM) is calculated.
The initial RIM value for a Realm is calculated from a subset of the Realm parameters.
A RIM is extended by applying the RHA to the inputs of RMM operations which are executed during Realm construction.
The following operations cause a RIM to be extended:
- Creation of a DATA Granule during Realm construction
- Creation of a runnable REC
- Changes to RIPAS of Protected IPA during Realm construction
On execution of an operation which requires extension of a RIM, the RMM first constructs a measurement descriptor structure. The measurement descriptor contents include the current RIM value. The new RIM value is computed by applying the RHA to the measurement descriptor.
On execution of an operation which requires extension of a RIM, the RMM first constructs a measurement descriptor structure. The measurement descriptor contents include the current RIM value. The new RIM value is computed by applying the RHA to the measurement descriptor.A RIM is immutable while the state of the Realm is REALM_ACTIVE. This implies that a RIM reflects the configuration and contents of the Realm at the moment when it transitioned from the REALM_NEW to the REALM_ACTIVE state.
A RIM depends upon the order of the RMM operations which are executed during Realm construction.
The order in which RMM operations are executed during Realm construction must be agreed between the Realm owner (or a delegate of the Realm owner which will receive and validate the RIM) and the Host which executes the RMM commands. This ensures that a correctly-constructed Realm will have the expected measurement.
The value of a RIM can be read using the RSI_MEASUREMENT_READ command.
7.1.2 Realm Extensible Measurement
This section describes the behavior of a Realm Extensible Measurement (REM).
A REM is extended using the RSI_MEASUREMENT_EXTEND command.
The value of a REM can be read using the RSI_MEASUREMENT_READ command.
The initial value of a REM is zero.
7.2 Realm attestation
This section describes the primitives which are used to support remote Realm attestation.
7.2.1 Attestation token
A CCA attestation token is a collection of claims about the state of a Realm and of the CCA platform on which the Realm is running.
A CCA attestation token consists of two parts:
Realm token
Contains attributes of the Realm, including:
- Realm Initial Measurement
- Realm Extensible Measurements
CCA platform token
Contains attributes of the CCA platform on which the Realm is running, including:
- CCA platform identity
- CCA platform lifecycle state
- CCA platform software component measurements
The size of a CCA attestation token may be greater than 4KB.
7.2.2 Attestation token generation
The process for a Realm to obtain an attestation token is:
- Call RSI_ATTESTATION_TOKEN_INIT once
- Call RSI_ATTESTATION_TOKEN_CONTINUE in a loop, until the result is not RSI_INCOMPLETE
Each call to RSI_ATTESTATION_TOKEN_CONTINUE retrieves up to one Granule of the attestation token.
Call RSI_ATTESTATION_TOKEN_INIT once Call RSI_ATTESTATION_TOKEN_CONTINUE in a loop, until the result is not RSI_INCOMPLETE The process for a Realm to obtain an attestation token is:The following pseudocode illustrates the process of a Realm obtaining an attestation token.
int get_attestation_token(...)
{
int ret;
uint64_t size, max_size;
uint64_t buf, granule;
ret = RSI_ATTESTATION_TOKEN_INIT(challenge, &max_size);
if (ret) {
return ret;
}
buf = alloc(max_size);
granule = buf;
do { // Retrieve one Granule of data per loop iteration
uint64_t offset = 0;
do { // Retrieve sub-Granule chunk of data per loop iteration
size = GRANULE_SIZE - offset;
ret = RSI_ATTESTATION_TOKEN_CONTINUE(granule, offset, size, &len);
offset += len;
} while (ret == RSI_INCOMPLETE && offset < GRANULE_SIZE);
// "offset" bytes of data are now ready for consumption from "granule"
if (ret == RSI_INCOMPLETE) {
granule += GRANULE_SIZE;
}
} while ((ret == RSI_INCOMPLETE) && (granule < buf + max_size));
return ret;
}The following pseudocode illustrates the process of a Realm obtaining anUp to one attestation token generation operation may be ongoing on a REC.
On execution of RSI_ATTESTATION_TOKEN_INIT, if an attestation token generation operation is ongoing on the calling REC, it is terminated.
The challenge value provided to RSI_ATTESTATION_TOKEN_INIT is included in the generated attestation token. This allows the relying party to establish freshness of the attestation token.
If the size of the challenge provided by the relying party is less than 64 bytes, it should be zero-padded prior to calling RSI_ATTESTATION_TOKEN_INIT. Arm recommends that the challenge should contain at least 32 bytes of unique data.
Up to oneGeneration of an attestation token generationcan be a long-running operation, during which interrupts may be ongoing on a RECneed to be handled.
If a physical interrupt becomes pending during execution of RSI_ATTESTATION_TOKEN_CONTINUE, a REC exit due to IRQ can occur.
On the next entry to the REC:
- If a virtual interrupt is pending on that REC, it is taken to the REC’s exception handler
- RSI_ATTESTATION_TOKEN_CONTINUE returns RSI_INCOMPLETE
- The REC should call RSI_ATTESTATION_TOKEN_CONTINUE again
See also:
7.2.3 Attestation token format
The CCA attestation token is a profiled IETF Entity Attestation Token (EAT).
The CCA attestation token is a Concise Binary Object Representation (CBOR) map, in which the map values are the Realm token and the CCA platform token.
The Realm token contains structured data in CBOR, wrapped with a COSE_Sign1 envelope according to the CBOR Object Signing and Encryption (COSE) standard.
The Realm token is signed by the Realm Attestation Key (RAK).
The CCA platform token contains structured data in CBOR, wrapped with a COSE_Sign1 envelope according to the COSE standard.
The CCA platform token is signed by the Initial Attestation Key (IAK).
The CCA platform token contains a hash of RAK_pub. This establishes a cryptographic binding between the Realm token and the CCA platform token.
The CCA attestation token is defined as follows:
cca-token = #6.399(cca-token-collection) ; CMW Collection
; (draft-ietf-rats-msg-wrap)
cca-platform-token = bstr .cbor COSE_Sign1_Tagged
cca-realm-delegated-token = bstr .cbor COSE_Sign1_Tagged
cca-token-collection = {
44234 => cca-platform-token ; 44234 = 0xACCA
44241 => cca-realm-delegated-token
}
; EAT standard definitions
COSE_Sign1_Tagged = #6.18(COSE_Sign1)
; Deliberately shortcut these definitions until EAT is finalised and able to
; pull in the full set of definitions
COSE_Sign1 = "COSE-Sign1 placeholder"The composition of the CCA attestation token format The composition of the CCA attestation token is summarised in the following figure.
See also:
7.2.3.1 Realm claims
This section defines the format of the Realm token claim map. The format is described using a combination of Concise Data Definition Language (CDDL) and text description.
The Realm token claim map is defined as follows:
cca-realm-claims = (cca-realm-claim-map)
cca-realm-claim-map = {
cca-realm-challenge
? cca-realm-profile
cca-realm-personalization-value
cca-realm-initial-measurement
cca-realm-extensible-measurements
cca-realm-hash-algo-id
cca-realm-public-key
cca-realm-public-key-hash-algo-id
cca-realm-mec-policy
}See also:
- Concise Data Definition Language (CDDL) [10]
- Section 7.2.3.1.1
- Section 7.2.3.1.2
- Section 7.2.3.1.3
- Section 7.2.3.1.4
- Section 7.2.3.1.5
- Section 7.2.3.1.6
- Section 7.2.3.1.7
- Section 7.2.3.1.8
- Section 7.2.3.1.9
- Section 7.2.3.1.10
- Section 7.2.3.1.11
7.2.3.1.1 Realm challenge claim
The Realm challenge claim is used to carry the challenge provided by the caller to demonstrate freshness of the generated token.
The Realm challenge claim is identified using the EAT
nonce label (10).
The length of the Realm challenge is 64 bytes.
The Realm challenge claim must be present in a Realm token.
The format of the Realm challenge claim is defined as follows:
cca-realm-challenge-label = 10
cca-realm-challenge-type = bytes .size 64
cca-realm-challenge = (
cca-realm-challenge-label => cca-realm-challenge-type
)7.2.3.1.2 Realm profile claim
The Realm profile claim identifies the EAT profile to which the Realm token conforms.
The Realm profile claim is identified using the EAT
profile label (265).
The Realm profile claim is optional in a CCA Realm token.
If the Realm profile is not included in a CCA Realm token then the profile value used in the CCA Platform token should refer to a profile that describes both Platform and Realm claims.
The format of the Realm profile claim is defined as follows:
cca-realm-profile-label = 265 ; EAT profile
cca-realm-profile-type = "tag:arm.com,2024:realm#1.1.0"
cca-realm-profile = (
cca-realm-profile-label => cca-realm-profile-type
)7.2.3.1.3 Realm Personalization Value claim
The Realm Personalization Value claim contains the RPV which was provided at Realm creation.
The Realm Personalization Value claim must be present in a Realm token.
The format of the Realm Personalization Value claim is defined as follows:
cca-realm-personalization-value-label = 44235
cca-realm-personalization-value-type = bytes .size 64
cca-realm-personalization-value = (
cca-realm-personalization-value-label => cca-realm-personalization-value-type
)See also:
- Section 2.1.3
7.2.3.1.4 Realm Initial Measurement claim
The Realm Initial Measurement claim contains the values of the Realm Initial Measurement.
The Realm Initial Measurement claim must be present in a Realm token.
The format of the Realm Initial Measurement claim is defined as follows:
cca-realm-measurement-type = bytes .size 32 / bytes .size 48 / bytes .size 64
cca-realm-initial-measurement-label = 44238
cca-realm-initial-measurement = (
cca-realm-initial-measurement-label => cca-realm-measurement-type
)7.2.3.1.5 Realm Extensible Measurements claim
The Realm Extensible Measurements claim contains the values of the Realm Extensible Measurements.
The Realm Extensible Measurements claim must be present in a Realm token.
The format of the Realm measurements claim is defined as follows:
cca-realm-measurement-type = bytes .size 32 / bytes .size 48 / bytes .size 64
cca-realm-extensible-measurements-label = 44239
cca-realm-extensible-measurements = (
cca-realm-extensible-measurements-label => [ 4*4 cca-realm-measurement-type ]
)7.2.3.1.6 Realm hash algorithm ID claim
The Realm hash algorithm ID claim identifies the algorithm used to calculate all hash values which are present in the Realm token.
Arm recommends that the value of the Realm hash algorithm ID claim is an IANA Hash Function name IANA Named Information Hash Algorithm Registry [11].
The Realm hash algorithm ID claim must be present in a Realm token.
The format of the Realm hash algorithm ID claim is defined as follows:
cca-realm-hash-algo-id-label = 44236
cca-realm-hash-algo-id = (
cca-realm-hash-algo-id-label => text
)7.2.3.1.7 Realm MEC policy claim
The Realm MEC policy identifies the MEC policy of the Realm.
The Realm MEC policy claim must be present in a Realm token.
On a platform which does not implement FEAT_MEC, the value of the Realm MEC policy claim is “shared”.
The format of the Realm MEC policy claim is defined as follows:
cca-realm-mec-policy-label = 44241
cca-realm-mec-policy = (
cca-realm-mec-policy-label => "shared" / "private"
)See also:
- Section 11
7.2.3.1.8 Realm public key claim
The Realm public key claim identifies the key which is used to sign the Realm token.
The value of the Realm public key claim is a CBOR bstr of a COSE_Key structure. The parameters used for the COSE_Key are profile-specific.
The Realm public key claim must be present in a Realm token.
The format of the Realm public key claim is defined as follows:
cca-realm-public-key-label = 44237
cca-realm-public-key-type = bstr .cbor COSE_Key
cca-realm-public-key = (
cca-realm-public-key-label => cca-realm-public-key-type
)
COSE_Key-label = int / tstr
COSE_Key-values = any
; See RFC8152 for full definition of COSE_Key
COSE_Key = {
1 => tstr / int, ; kty
? 2 => bstr, ; kid
? 3 => tstr / int, ; alg
? 4 => [+ (tstr / int) ], ; key_ops
? 5 => bstr, ; Base IV
* COSE_Key-label => COSE_Key-values
}See also:
- SEC 1: Elliptic Curve Cryptography, version 2.0 [12]
- Section 7.2.3.1.9
- Section 7.2.3.2.2
7.2.3.1.9 Realm public key hash algorithm identifier claim
The Realm public key hash algorithm identifier claim identifies the algorithm used to calculate H(RAK_pub).
The Realm public key hash algorithm identifier claim must be present in a Realm token.
The format of the Realm public key hash algorithm identifier claim is defined as follows:
cca-realm-public-key-hash-algo-id-label = 44240
cca-realm-public-key-hash-algo-id = (
cca-realm-public-key-hash-algo-id-label => text
)See also:
- SEC 1: Elliptic Curve Cryptography, version 2.0 [12]
- Section 7.2.3.1.8
- Section 7.2.3.2.2
7.2.3.1.10 Collated CDDL for Realm claims
The format of the Realm token claim map is defined as follows:
cca-realm-claims = (cca-realm-claim-map)
cca-realm-claim-map = {
cca-realm-challenge
? cca-realm-profile
cca-realm-personalization-value
cca-realm-initial-measurement
cca-realm-extensible-measurements
cca-realm-hash-algo-id
cca-realm-public-key
cca-realm-public-key-hash-algo-id
cca-realm-mec-policy
}
cca-realm-challenge-label = 10
cca-realm-challenge-type = bytes .size 64
cca-realm-challenge = (
cca-realm-challenge-label => cca-realm-challenge-type
)
cca-realm-profile-label = 265 ; EAT profile
cca-realm-profile-type = "tag:arm.com,2024:realm#1.1.0"
cca-realm-profile = (
cca-realm-profile-label => cca-realm-profile-type
)
cca-realm-personalization-value-label = 44235
cca-realm-personalization-value-type = bytes .size 64
cca-realm-personalization-value = (
cca-realm-personalization-value-label => cca-realm-personalization-value-type
)
cca-realm-measurement-type = bytes .size 32 / bytes .size 48 / bytes .size 64
cca-realm-initial-measurement-label = 44238
cca-realm-initial-measurement = (
cca-realm-initial-measurement-label => cca-realm-measurement-type
)
cca-realm-extensible-measurements-label = 44239
cca-realm-extensible-measurements = (
cca-realm-extensible-measurements-label => [ 4*4 cca-realm-measurement-type ]
)
cca-realm-hash-algo-id-label = 44236
cca-realm-hash-algo-id = (
cca-realm-hash-algo-id-label => text
)
cca-realm-public-key-label = 44237
cca-realm-public-key-type = bstr .cbor COSE_Key
cca-realm-public-key = (
cca-realm-public-key-label => cca-realm-public-key-type
)
COSE_Key-label = int / tstr
COSE_Key-values = any
; See RFC8152 for full definition of COSE_Key
COSE_Key = {
1 => tstr / int, ; kty
? 2 => bstr, ; kid
? 3 => tstr / int, ; alg
? 4 => [+ (tstr / int) ], ; key_ops
? 5 => bstr, ; Base IV
* COSE_Key-label => COSE_Key-values
}
cca-realm-public-key-hash-algo-id-label = 44240
cca-realm-public-key-hash-algo-id = (
cca-realm-public-key-hash-algo-id-label => text
)
cca-realm-mec-policy-label = 44241
cca-realm-mec-policy = (
cca-realm-mec-policy-label => "shared" / "private"
)7.2.3.1.11 Example Realm claims
An example Realm claim map is shown below in COSE-DIAG format:
/ Realm claim map /
{
/ cca-realm-profile /
265: "tag:arm.com,2024:realm#1.1.0",
/ cca-realm-challenge /
10: h'ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABAB
ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABAB',
/ cca-realm-personalization-value /
44235: h'ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABAB
ABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABAB',
/ cca-realm-initial-measurement /
44238: h'0000000000000000000000000000000000000000000000000000000000000000',
/ cca-realm-extensible-measurements /
44239: [
h'0000000000000000000000000000000000000000000000000000000000000000',
h'0000000000000000000000000000000000000000000000000000000000000000',
h'0000000000000000000000000000000000000000000000000000000000000000',
h'0000000000000000000000000000000000000000000000000000000000000000'
],
/ cca-realm-hash-algo-id /
44236: "sha-256",
/ cca-realm-public-key /
44237: h'A50102033823200221582066EEA6A22678C3A9F83148EF349800B20ABB486F2C
C6D7ED017EC49798C8D4372258202F25DE86812374E6E8D48DEE8E230AD29CCD
839BE6E0DB8C7AB9DEDE0805D29D',
/ cca-realm-public-key-hash-algo-id /
44240: "sha-256",
/ cca-realm-mec-policy /
44241: "private"
}7.2.3.2 CCA platform claims
This section defines the format of the CCA platform token claim map. The format is described using a combination of Concise Data Definition Language (CDDL) and text description.
The CCA platform token claim map is defined as follows:
cca-platform-claims = (cca-platform-claim-map)
cca-platform-claim-map = {
cca-platform-profile
cca-platform-challenge
cca-platform-implementation-id
cca-platform-instance-id
cca-platform-config
cca-platform-lifecycle
cca-platform-sw-components
? cca-platform-verification-service
cca-platform-hash-algo-id
}See also:
7.2.3.2.1 CCA platform profile claim
The CCA platform profile claim identifies the EAT profile to which the CCA platform token conforms. Note that because the platform token is expected to be issued when bound to a Realm token, the profile document should also include the relevant Realm profile or a reference to that profile.
The CCA platform profile claim is identified using the EAT
profile label (265).
The CCA platform profile claim must be present in a CCA platform token.
The format of the CCA platform profile claim is defined as follows:
cca-platform-profile-label = 265 ; EAT profile
cca-platform-profile-type = "tag:arm.com,2024:cca_platform#1.1.0"
cca-platform-profile = (
cca-platform-profile-label => cca-platform-profile-type
)7.2.3.2.2 CCA platform challenge claim
The CCA platform challenge claim contains a hash of the public key used to sign the Realm token.
The CCA platform challenge claim is identified using the EAT
nonce label (10).
The length of the CCA platform challenge is either 32, 48 or 64 bytes.
The CCA platform challenge claim must be present in a CCA platform token.
The format of the CCA platform challenge claim is defined as follows:
cca-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64
cca-platform-challenge-label = 10
cca-platform-challenge = (
cca-platform-challenge-label => cca-hash-type
)See also:
- Section 7.2.3.1.8
7.2.3.2.3 CCA platform Implementation ID claim
The CCA platform Implementation ID claim uniquely identifies the implementation of the CCA platform.
The value of the CCA platform Implementation ID claim can be used by a verification service to locate the details of the CCA platform implementation from an endorser or manufacturer. Such details are used by a verification service to determine the security properties or certification status of the CCA platform implementation.
The semantics of the CCA platform Implementation ID value are defined by the manufacturer or a particular certification scheme. For example, the ID could take the form of a product serial number, database ID, or other appropriate identifier.
The CCA platform Implementation ID claim does not identify a particular instance of the CCA implementation.
The CCA platform Implementation ID claim must be present in a CCA platform token.
The format of the CCA platform Implementation ID claim is defined as follows:
cca-platform-implementation-id-label = 2396 ; PSA implementation ID
cca-platform-implementation-id-type = bytes .size 32
cca-platform-implementation-id = (
cca-platform-implementation-id-label => cca-platform-implementation-id-type
)See also:
- Arm CCA Security model [4]
- Section 7.2.3.2.4
7.2.3.2.4 CCA platform Instance ID claim
The CCA platform Instance ID claim represents the unique identifier of the Initial Attestation Key (IAK) for the CCA platform.
The CCA platform Instance ID claim is identified using the EAT
ueid label (256).
The first byte of the CCA platform Instance ID value must be
0x01.
The CCA platform Instance ID claim must be present in a CCA platform token.
The format of the CCA platform Instance ID claim is defined as follows:
cca-platform-instance-id-label = 256 ; EAT ueid
; TODO: require that the first byte of cca-platform-instance-id-type is 0x01
; EAT UEIDs need to be 7 - 33 bytes
cca-platform-instance-id-type = bytes .size 33
cca-platform-instance-id = (
cca-platform-instance-id-label => cca-platform-instance-id-type
)See also:
- Arm CCA Security model [4]
- Section 7.2.3.2.3
7.2.3.2.5 CCA platform config claim
The CCA platform config claim describes the set of chosen implementation options of the CCA platform. As an example, these may include a description of the level of physical memory protection which is provided.
The CCA platform config claim is expected to contain the System Properties field which is present in the Root Non-volatile Storage (RNVS) public parameters.
The CCA platform config claim must be present in a CCA platform token.
cca-platform-config-label = 2401 ; PSA platform range
; TBD: add to IANA registration
cca-platform-config-type = bytes
cca-platform-config = (
cca-platform-config-label => cca-platform-config-type
)See also:
7.2.3.2.6 CCA platform lifecycle claim
The CCA platform lifecycle claim identifies the lifecycle state of the CCA platform.
The value of the CCA platform lifecycle claim is an integer which is divided as follows:
- value[15:8]: CCA platform lifecycle state
- value[7:0]: implementation defined
The CCA platform lifecycle claim must be present in a CCA platform token.
A non debugged CCA platform will be in psa-lifecycle-secured state. Realm Management Security Domain debug is always recoverable, and would therefore be represented by psa-lifecycle-non-psa-rot-debug state. Root world debug is recoverable on a HES system and would be represented by psa-lifecycle-recoverable-psa-rot state. On a non-HES system Root world debug is usually non-recoverable, and would be represented by psa-lifecycle-lifecycle-decommissioned state.
The format of the CCA platform lifecycle claim is defined as follows:
cca-platform-lifecycle-label = 2395 ; PSA lifecycle
cca-platform-lifecycle-unknown-type = 0x0000..0x00ff
cca-platform-lifecycle-assembly-and-test-type = 0x1000..0x10ff
cca-platform-lifecycle-cca-platform-rot-provisioning-type = 0x2000..0x20ff
cca-platform-lifecycle-secured-type = 0x3000..0x30ff
cca-platform-lifecycle-non-cca-platform-rot-debug-type = 0x4000..0x40ff
cca-platform-lifecycle-recoverable-cca-platform-rot-debug-type = 0x5000..0x50ff
cca-platform-lifecycle-decommissioned-type = 0x6000..0x60ff
cca-platform-lifecycle-type =
cca-platform-lifecycle-unknown-type /
cca-platform-lifecycle-assembly-and-test-type /
cca-platform-lifecycle-cca-platform-rot-provisioning-type /
cca-platform-lifecycle-secured-type /
cca-platform-lifecycle-non-cca-platform-rot-debug-type /
cca-platform-lifecycle-recoverable-cca-platform-rot-debug-type /
cca-platform-lifecycle-decommissioned-type
cca-platform-lifecycle = (
cca-platform-lifecycle-label => cca-platform-lifecycle-type
)See also:
7.2.3.2.7 CCA platform software components claim
The CCA platform software components claim is a list of software components which can affect the behavior of the CCA platform. It is expected that an implementation will describe the expected software component values within the profile.
In some implementations, a software component may consist of a configuration data item.
The CCA platform software components claim must be present in a CCA platform token.
The format of the CCA platform software components claim is defined as follows:
cca-platform-sw-components-label = 2399 ; PSA software components
cca-platform-sw-component = {
? 1 => text, ; component type
2 => cca-hash-type, ; measurement value
? 4 => text, ; version
5 => cca-hash-type, ; signer id
? 6 => text, ; hash algorithm identifier
? 7 => bool, ; live firmware activation supported
? 8 => [ + cca-hash-type ], ; list of countersigner ids
}
cca-platform-sw-components = (
cca-platform-sw-components-label => [ + cca-platform-sw-component ]
)7.2.3.2.7.1 CCA platform software component type
The CCA platform software component type is a string which represents the role of the software component.
The CCA platform software component type is intended for use as a hint to help the relying party understand how to evaluate the CCA platform software component measurement value.
The CCA platform software component type is optional in a CCA platform token.
If the CCA platform supports Live Firmware Activation, one entry in the platform software component table is reserved to act as a measurement register for the Firmware Activity Log. This entry is identified by having a software component type of “FAL”.
See also:
- Section 3.12
7.2.3.2.7.2 CCA platform software component measurement value
The CCA platform software component measurement value represents a hash of the state of the software component in memory at the time it was initialized.
The CCA platform software component measurement value must be a hash of 256 bits or stronger.
The CCA platform software component measurement value must be present in a CCA platform token.
7.2.3.2.7.3 CCA platform software component version
The CCA platform software component version is a text string whose meaning is defined by the software component vendor.
The CCA platform software component version is optional in a CCA platform token.
7.2.3.2.7.4 CCA platform software component signer ID
The CCA platform software component signer ID is the hash of a signing authority public key for the software component. It can be used by a verifier to ensure that the software component was signed by an expected trusted source.
The CCA platform software component signer ID value must be a hash of 256 bits or stronger.
The CCA platform software signer ID must be present in a CCA platform token.
7.2.3.2.7.5 CCA platform software component hash algorithm ID
The CCA platform software component hash algorithm ID identifies the way in which the hash algorithm used to measure the CCA platform software component.
Arm recommends that the value of the CCA platform software component hash algorithm ID is an IANA Hash Function name IANA Named Information Hash Algorithm Registry [11].
Arm recommends that the hash algorithm used to measure the CCA platform software component is one of the algorithms listed in the Arm CCA Security model [4].
The CCA platform software component hash algorithm ID is optional in a CCA platform token.
7.2.3.2.7.6 CCA platform software component Live Firmware Activation support
The CCA platform software component Live Firmware Activation support attribute declares whether an individual component is subject to Live Firmware Activation. If the attribute is False, the component will not be updated before the next CCA platform reset.
The CCA platform software component Live Firmware activation support attribute is optional in a CCA platform token.
See also:
- Section 3.12
7.2.3.2.7.7 CCA platform software component countersigner ID list
The CCA platform software component countersigner ID list contains hashes of public keys which identify signing authorities that provides additional trustworthiness information for the software component. These signatures are provided in addition to the primary signature, which is identified by the CCA platform software component signer ID.
Example use cases for CCA platform software component countersignatures include:
- An indication of approval for the component, provided by the owner of the CCA platform
- An indication of approval for the component, provided by a third party auditor
The order of multiple entries within the countersigner ID list may imply a hierarchy. The existence and meaning of any such hierarchy is implementation defined.
The CCA platform software component countersigner ID list is optional in a CCA platform token.
7.2.3.2.8 CCA platform verification service claim
The CCA platform verification service claim is a hint which can be used by a relying party to locate a verifier for the token.
The value of the CCA platform verification service claim is a text string which can be used to locate the service or a URL specifying the address of the service.
The CCA platform verification service claim may be ignored by a relying party in favor of other information.
The CCA platform verification service claim is optional in a CCA platform token.
The format of the CCA platform verification service claim is defined as follows:
cca-platform-verification-service-label = 2400 ; PSA verification service
cca-platform-verification-service-type = text
cca-platform-verification-service = (
cca-platform-verification-service-label =>
cca-platform-verification-service-type
)7.2.3.2.9 CCA platform hash algorithm ID claim
The CCA platform hash algorithm ID claim identifies the default algorithm used to calculate measurements in the CCA platform token.
The default hash algorithm may be overridden for an individual software component, by the CCA platform software component hash algorithm ID claim.
Arm recommends that the value of the CCA platform hash algorithm ID claim is an IANA Hash Function name IANA Named Information Hash Algorithm Registry [11].
The CCA platform hash algorithm ID claim must be present in a CCA platform token.
The format of the CCA platform hash algorithm ID claim is defined as follows:
cca-platform-hash-algo-id-label = 2402 ; PSA platform range
; TBD: add to IANA registration
cca-platform-hash-algo-id = (
cca-platform-hash-algo-id-label => text
)7.2.3.3 Attestation token format compatibility
The table below summarises the support for each claim, depending on
the version of the profile of the attestation token. The profile version
is reported in the cca-platform-profile claim as
http://arm.com/CCA-SSD/VERSION.
| Claim | Version | |
|---|---|---|
| 1.0.0 | 1.1.0 | |
| cca-platform-profile | Required | Required |
| cca-platform-challenge | Required | Required |
| cca-platform-implementation-id | Required | Required |
| cca-platform-instance-id | Required | Required |
| cca-platform-config | Required | Required |
| cca-platform-lifecycle | Required | Required |
| cca-platform-sw-components | Required:
Optional:
|
Required
Optional:
|
| cca-platform-verification-service | Optional | Optional |
| cca-platform-hash-algo-id | Required | Required |
| cca-realm-challenge | Required | Required |
| cca-realm-personalization-value | Required | Required |
| cca-realm-initial-measurement | Required | Required |
| cca-realm-extensible-measurements | Required | Required |
| cca-realm-hash-algo-id | Required | Required |
| cca-realm-mec-policy | Not supported | Required |
| cca-realm-public-key | Required | Required |
| cca-realm-public-key-hash-algo-id | Required | Required |
7.2.3.3.1 Collated CDDL for CCA platform claims
The format of the CCA platform token claim map is defined as follows:
cca-platform-claims = (cca-platform-claim-map)
cca-platform-claim-map = {
cca-platform-profile
cca-platform-challenge
cca-platform-implementation-id
cca-platform-instance-id
cca-platform-config
cca-platform-lifecycle
cca-platform-sw-components
? cca-platform-verification-service
cca-platform-hash-algo-id
}
cca-platform-profile-label = 265 ; EAT profile
cca-platform-profile-type = "tag:arm.com,2024:cca_platform#1.1.0"
cca-platform-profile = (
cca-platform-profile-label => cca-platform-profile-type
)
cca-hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64
cca-platform-challenge-label = 10
cca-platform-challenge = (
cca-platform-challenge-label => cca-hash-type
)
cca-platform-implementation-id-label = 2396 ; PSA implementation ID
cca-platform-implementation-id-type = bytes .size 32
cca-platform-implementation-id = (
cca-platform-implementation-id-label => cca-platform-implementation-id-type
)
cca-platform-instance-id-label = 256 ; EAT ueid
; TODO: require that the first byte of cca-platform-instance-id-type is 0x01
; EAT UEIDs need to be 7 - 33 bytes
cca-platform-instance-id-type = bytes .size 33
cca-platform-instance-id = (
cca-platform-instance-id-label => cca-platform-instance-id-type
)
cca-platform-config-label = 2401 ; PSA platform range
; TBD: add to IANA registration
cca-platform-config-type = bytes
cca-platform-config = (
cca-platform-config-label => cca-platform-config-type
)
cca-platform-lifecycle-label = 2395 ; PSA lifecycle
cca-platform-lifecycle-unknown-type = 0x0000..0x00ff
cca-platform-lifecycle-assembly-and-test-type = 0x1000..0x10ff
cca-platform-lifecycle-cca-platform-rot-provisioning-type = 0x2000..0x20ff
cca-platform-lifecycle-secured-type = 0x3000..0x30ff
cca-platform-lifecycle-non-cca-platform-rot-debug-type = 0x4000..0x40ff
cca-platform-lifecycle-recoverable-cca-platform-rot-debug-type = 0x5000..0x50ff
cca-platform-lifecycle-decommissioned-type = 0x6000..0x60ff
cca-platform-lifecycle-type =
cca-platform-lifecycle-unknown-type /
cca-platform-lifecycle-assembly-and-test-type /
cca-platform-lifecycle-cca-platform-rot-provisioning-type /
cca-platform-lifecycle-secured-type /
cca-platform-lifecycle-non-cca-platform-rot-debug-type /
cca-platform-lifecycle-recoverable-cca-platform-rot-debug-type /
cca-platform-lifecycle-decommissioned-type
cca-platform-lifecycle = (
cca-platform-lifecycle-label => cca-platform-lifecycle-type
)
cca-platform-sw-components-label = 2399 ; PSA software components
cca-platform-sw-component = {
? 1 => text, ; component type
2 => cca-hash-type, ; measurement value
? 4 => text, ; version
5 => cca-hash-type, ; signer id
? 6 => text, ; hash algorithm identifier
? 7 => bool, ; live firmware activation supported
? 8 => [ + cca-hash-type ], ; list of countersigner ids
}
cca-platform-sw-components = (
cca-platform-sw-components-label => [ + cca-platform-sw-component ]
)
cca-platform-verification-service-label = 2400 ; PSA verification service
cca-platform-verification-service-type = text
cca-platform-verification-service = (
cca-platform-verification-service-label =>
cca-platform-verification-service-type
)
cca-platform-hash-algo-id-label = 2402 ; PSA platform range
; TBD: add to IANA registration
cca-platform-hash-algo-id = (
cca-platform-hash-algo-id-label => text
)7.2.3.3.2 Example CCA platform claims
An example CCA platform claim map is shown below in COSE-DIAG format:
/ CCA platform claim map /
{
/ cca-platform-profile /
265: "tag:arm.com,2024:cca_platform#1.1.0",
/ cca-platform-challenge /
10: h'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA',
/ cca-platform-implementation-id /
2396: h'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA',
/ cca-platform-instance-id /
256: h'010BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BB',
/ cca-platform-config /
2401: h'CFCFCFCF',
/ cca-platform-lifecycle /
2395: 12288,
/ cca-platform-sw-components /
2399: [
{
/ measurement value /
2: h'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA',
/ signer id /
5: h'BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB',
/ version /
4: "1.0.0",
/ hash algorithm identifier /
6: "sha-256"
},
{
/ measurement value /
2: h'CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC',
/ signer id /
5: h'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD',
/ version /
4: "1.0.0",
/ hash algorithm identifier /
6: "sha-256"
}
],
/ cca-platform-verification-service /
2400: "https://cca_verifier.org",
/ cca-platform-hash-algo-id /
2402: "sha-256"
}8 Realm debug and performance monitoring
This section describes the debug and performance monitoring features which are available to a Realm.
8.1 Realm PMU
This section describes the programming model for usage of PMU by a Realm.
On REC entry, Realm PMU state is restored from the REC object.
On REC exit, all Realm PMU state is saved to the REC object.
On REC exit, exit.pmu_ovf_status indicates the status of
the PMU overflow at the time of the Realm exit.
9 Realm device assignment
This section describes how devices are assigned to Realms, attested and granted permission to access Realm-owned memory.
9.1 Realm device assignment overview
The RMM allows a device to be assigned to a Realm in a trustworthy manner, allowing the Realm to attest the identity and configuration of the device before it is permitted to access the Realm’s memory.
Interaction betweenFrom the Host and a PDEV object or VDEV object is performed via RMI commands.point of view, devices are managed using two types of RMM object:
Physical Device (PDEV)
Represents a communication channel between the RMM and a physical device, for example a PCIe device.
Virtual Device (VDEV)
Represents the binding between a device function and a Realm. For example, a VDEV can represent a physical function of a PCIe device or a virtual function of a multi-function PCIe device. Every VDEV is associated with one PDEV.
FromInteraction between the Host point of view, devices are managed using two types of RMM object:and a PDEV object or VDEV object is performed via RMI commands.
Interaction betweenFrom the Realm and an RDEV is performed via RSI commands. From the Realm point of view, an assigned device function is represented by a Realm Device (RDEV).
Interaction between the Realm and an RDEV is performed via RSI commands.
Arm expects that a VDEV and an RDEV will both refer to the same data structure inside the RMM.
A platform-attested device is a device whose identity and firmware are attested as part of the CCA platform.
A device which is physically integrated into the platform and which does not implement its own Device Security Manager (DSM) is a platform-attested device.
An independently-attested device is a device whose identity and firmware are attested separately from the CCA platform.
An independently-attested device implements its own DSM.
9.1.1 Assignment of an independently-attested device
The communication channel between the RMM and an independently-attested device is managed by the Host.
Communication between the RMM and an independently-attested device is protected using the Security Protocol and Data Model (SPDM) protocol.
Identify of an independently-attested device is described by a device certificate.
Firmware measurements for an independently-attested device are reported in an SPDM measurement block.
Assignment of an independently-attested device to a Realm involves the following steps:
The Host creates a PDEV object, associated with the target physical device.
The Host initializes the PDEV object, causing the following to happen:
A secure channel is established between the RMM and the device.
The physical link between the device and memory is secured. For example, for an off-chip PCIe device, this is achieved using the Integrity and Data Encryption (IDE) standard. See PCI Express 6.0 specification [14].
The device certificate is provided to the Host. The Host is expected to store this information, and to later present it to the Realm.
A digest of the device certificate is stored by the RMM. This is used later to check integrity of the attestation evidence provided by the Host to the Realm.
The Host creates a VDEV object, which represents a binding between a function of the target device, and a Realm. At this stage, the target device is not granted access to the Realm-owned memory.
The Host maps memory regions of the target device function into the Protected IPA space of the Realm. At this stage, the mappings are invalid, so the Realm cannot yet access the device’s memory regions.
Device information provided by the RMM tells the Realm that the device is independently-attested. The Realm requests the RMM to retrieve device attestation evidence (device interface report and device measurements.) As with the device certificate, the evidence is provided to the Host for caching, and the RMM stores digests of the evidence. The Realm later requests device attestation evidence from the Host, and verifies that this matches the corresponding digests stored by the RMM.
The Realm verifies that the device identity (represented by the device certificate) and device measurements are acceptable.
The Realm verifies that device memory mappings created by the Host match those described in the device interface report. Once each mapping has been verified, it is made valid by the RMM, so the Realm can access the device’s memory regions.
The Realm instructs the RMM to grant the device access to Realm-owned memory.
Requiring the Host to store device attestation evidence means that storage for this information, whose size may not be known ahead of time, does not need to be allocated in RMM memory. The RMM therefore only needs to store a digest of the Host-cached data, which can be used by the Realm to check integrity of data retrieved from the Host.
Assignment of an independently-attested device to a Realm involves is illustrated in the following steps: X Requiring the Host to store device attestation evidence means that storage for this information, whose size may not be known ahead of time, does not need to be allocated in RMM memory. The RMM therefore only needs to store a digest of the Host-cached data, which can be used by the Realm to check integrity of data retrieved from the Hostsequence diagram.
I Note that “secure SPDM” means that the requester (the RMM) has verified that the responder holds the private key which was used to sign the device certificate. The identity and trustworthiness of the responder are not evaluated until the Realm receives attestation evidence for the device.
Assignment of an independently-attestedNote that “secure SPDM” means that the requester (the RMM) has verified that the responder holds the private key which was used to sign the device to acertificate. The identity and trustworthiness of the responder are not evaluated until the Realm is illustrated in the following sequence diagramreceives attestation evidence for the device.
9.1.2 Assignment of a platform-attested device
The communication channel between the RMM and a platform-attested device is implementation defined.
Firmware measurements for a platform-attested device are reported in the CCA platform software components claim.
Assignment of a platform-attested device to a Realm involves the following steps:
The Host creates a PDEV object, associated with the target physical device.
The Host initializes the PDEV object, causing the following to happen:
- A secure channel is established between the RMM and the device.
The Host creates a VDEV object, which represents a binding between a function of the target device, and a Realm. At this stage, the target device is not granted access to the Realm-owned memory.
The Host maps memory regions of the target device function into the Protected IPA space of the Realm. At this stage, the mappings are invalid, so the Realm cannot yet access the device’s memory regions.
Device information provided by the RMM tells the Realm that the device is platform-attested. The Realm requests the RMM to retrieve a device interface report. The device interface report is provided to the Host for caching, and the RMM stores digests of the device interface report. The Realm later requests the device interface report from the Host, and verifies that this matches the corresponding digest stored by the RMM.
The Realm retrieves device measurements from the CCA platform attestation token, and verifies that the measurements are acceptable.
The Realm verifies that device memory mappings created by the Host match those described in the device interface report. Once each mapping has been verified, it is made valid by the RMM, so the Realm can access the device’s memory regions.
The Realm instructs the RMM to grant the device access to Realm-owned memory.
Assignment of a platform-attested device to a Realm involves the is illustrated in the following steps:sequence diagram.
I
See also:
- Section 7.2.3.2.7
9.2 Communication between RMM and a device
9.2.1 Device requests and responses
Communication between the RMM and a device consists of a series of device requests sent from the RMM to the device and device responses returned by the device to the RMM.
A device transaction is a series of one or more (device request, device response) tuples.
At the requester side (that is, at the RMM), a device transaction is associated with either a PDEV or a VDEV, depending on the event which triggered the device transaction:
- If the device transaction was triggered by one of the following RMI
commands then the device transaction is associated with the PDEV.
- RMI_PDEV_CREATE
- RMI_PDEV_SET_PUBKEY
- RMI_PDEV_NOTIFY
- RMI_PDEV_STOP
- If the device transaction was triggered by one of the following RMI
commands then the device transaction is associated with the VDEV.
- RMI_VDEV_STOP
- If the device transaction was triggered by one of the following RSI
commands then the device transaction is associated with the VDEV.
- RSI_RDEV_GET_INTERFACE_REPORT
- RSI_RDEV_GET_MEASUREMENTS
- RSI_RDEV_LOCK
- RSI_RDEV_START
- RSI_RDEV_STOP
A PDEV is associated with at most one device transaction at a time.
A VDEV is associated with at most one device transaction at a time.
During communicationCommunication between the RMM and an off-chip device consists of SPDM messages, device requests and device responses are transported via Non-secure memory.
During communicationCommunication between the RMM and an offon-chip device can occur via one of two paths:
- SPDM messages, transported via Non-secure memory.
- Platform communication, via an implementation defined channel.
When the RMM requires the Host programs the physical to send a device interfacerequest, the “send” flag is set in the DevCommExitFlags fieldset.
When the RMM sends a device request via an implementation defined channel, the “send” flag is clear and the “wait” flag is set in the DevCommExitFlags fieldset. This informs the Host that it should either:
- Register for an implementation defined notification that the request has been completed, and call RMI_PDEV_COMMUNICATE or RMI_VDEV_COMMUNICATE when this notification is received, or
- Poll for request completion by periodically calling RMI_PDEV_COMMUNICATE or RMI_VDEV_COMMUNICATE.
The states of a Device communication are listed below.
| State | Description |
|---|---|
| DEV_COMM_IDLE | The RMM is not communicating with the device. |
| DEV_COMM_PENDING | The RMM has a device request which is ready to be sent to the device. |
| DEV_COMM_ACTIVE | The RMM has initiated a device transaction. One or more device requests associated with this device transaction have been sent from the RMM to the device. The RMM has not received all the expected device responses associated with this device transaction. |
| DEV_COMM_ERROR | The RMM encountered an error during communication with the device. |
Device communication state transitions are shown in the following figure. Each arc is labeled with the events which can cause the corresponding state transition.
See also:
- Secured Messages using SPDM Specification version 1.1.0 [15]
- Section 9.5.1
- Section 15.4.9
9.2.2 Mapping from virtual device ID to VDEV object
The RMM does not maintain a mapping from virtual device ID to VDEV object. Conseqeuntly, when a Realm executes the RSI_RDEV_GET_INFO command, passing a virtual device ID, the RMM must request the Host to provide a corresponding VDEV object.
The following sequence diagram shows how the virtual device ID passed by a Realm is mapped to a corresponding VDEV object.
The data structure returned from RSI_RDEV_GET_INFO includes a “device instance ID” value. The device instance ID is guaranteed to be unique among VDEVs owned by the calling Realm, unlike the virtual device ID. When the Realm calls any RSI_RDEV command other than RSI_RDEV_GET_INFO, it passes the (virtual device ID, instance ID) tuple.
The following sequence diagram shows how the (virtual device ID, instance ID) tuple passed by a Realm is mapped to the corresponding VDEV object.
See also:
9.2.3 Host-side device communication flow
The RMI_PDEV_COMMUNICATE command is used to send a PDEV-associated device request from the RMM to a device, and / or to return a device response from the device to the RMM.
The RMI_VDEV_COMMUNICATE command is used to send a VDEV-associated device request from the RMM to a device, and / or to return a device response from the device to the RMM.
The RMI_PDEV_COMMUNICATE and RMI_VDEV_COMMUNICATE commands have identical programming models. Hereafter, they are referred to collectively as “device communication commands”.
For a given physical device, at most one device transaction can be active.
The RMI_PDEV_ABORT command or RMI_VDEV_ABORT command is used to abort an DEV_COMM_ACTIVE device transaction.
At the responder side (that is, at the device), device transactions associated with a PDEV and device transactions associated with its child VDEVs all terminate at the same physical device.
9.2.3.1 Communication flow for devices which use SPDM
The overall flow for communication between the RMM and a device which uses SPDM is as follows:
The RMM indicates to the Host that a device transaction, associated with a specified PDEV or VDEV, is DEV_COMM_PENDING.
- If the device transaction was triggered by execution of an RMI command, this indication is provided via the command’s output values.
- If the device transaction was triggered by execution of an RSI command, this indication is provided via a REC exit due to device communication.
The RMM also indicates to the Host whether the pending transaction will contain more than one (device request, device response) tuple.
The Host calls the appropriate device communication command.
Input values to the command include a device request buffer, which is a pointer to a Granule of NS memory.
The RMM writes a device request to the device request buffer and returns to the Host, indicating that data is ready to be sent to the device. The device request is guaranteed to be no larger than 4KB.
The Host sends the device request to the device.
Details of how this is performed are out of scope of this specification. For an off-chip PCIe device, this could be done by copying from the device request buffer to a Data Object Exchange (DOE) mailbox.
The device communication state becomes DEV_COMM_ACTIVE.
The device indicates to the Host that it has responded to the request.
The Host copies the device response to a device response buffer in NS memory. As with sending the request, details of how this are out of scope of this specification.
The Host calls the device communication command, providing a pointer to the device response buffer.
The return value indicates that either:
- The RMM has another device request to send within the same device transaction (in which case the flow returns to step 2), or
- The device transaction is complete.
If the device transaction is incomplete, the Host checks the device state to determine whether an error has occurred.
When multiple device transactions destined for the same physical device are DEV_COMM_PENDING, the Host is free to choose which of them to transition to DEV_COMM_ACTIVE.
When a device transaction is DEV_COMM_ACTIVE, the Host must not send to that physical device a device request associated with any other device transaction.
The SPDM session which is established between the RMM and a device has the following characteristics:
- SPDM measurements use DMTF format
- SPDM heartbeat is not supported
- SPDM key update is not supported
The In order for its functions to be assignable to Realms, a device must provide the following functionality:
- SPDM session which is established between the RMM and a device has the following characteristics:version required by PCIe TDISP and IDE_KM specifications.
- Identity and authentication including key exchange.
See also:
9.2.3.2 Communication flow for devices which do not use SPDM
The overall flow for communication between the RMM and a device which does not use SPDM is as follows:
The RMM indicates to the Host that a device transaction, associated with a specified PDEV or VDEV, is DEV_COMM_PENDING.
- If the device transaction was triggered by execution of an RMI command, this indication is provided via the command’s output values.
- If the device transaction was triggered by execution of an RSI command, this indication is provided via a REC exit due to device communication.
The Host calls the appropriate device communication command repeatedly, until either:
- The return value indicates that the device transaction is complete.
- The device enters an error state.
See also:
- Section 4.3.11
9.2.4 Host caching of device attestation evidence
On execution of a device communication command, the RMM can indicate to the Host that the Host should cache data from the response buffer, for later retrieval by the Realm.
The identity of the data which the Host is requested to cache is implied by the command which triggered the device transaction, as follows:
- If the device transaction was triggered while the PDEV state was PDEV_NEW then the cached data is a device certificate.
- If the device transaction was triggered by RSI_RDEV_GET_INTERFACE_REPORT then the cached data is a device interface report.
- If the device transaction was triggered by RSI_RDEV_GET_MEASUREMENTS then the cached data is a device measurement block.
9.2.5 Device communication data structures
9.2.5.1 Device communication exit data structure
An RmiDevCommExit object is a data structure which is passed from the RMM to the Host during a device transaction.
The attributes of an RmiDevCommExit object tell the Host the following:
- Whether there is data in the device response buffer which the Host is requested to cache. This is indicated by the RmiDevCommExitFlags::cache flag.
- Whether the device request buffer contains a device request which the Host is requested to send to the device. This is indicated by the RmiDevCommExitFlags::send flag.
- Whether the RMM is waiting for a response from the device. This is indicated by the RmiDevCommExitFlags::wait flag.
- Whether the device transaction contains more than one (device request, device response) tuple. This is indicated by the RmiDevCommExitFlags::multi flag.
RmiDevCommExitFlags::send and RmiDevCommExitFlags::wait are never set together.
RmiDevCommExitFlags::multi is only set when RmiDevCommExitFlags::send is set.
During communication between the RMM and a device which uses SPDM:
- RmiDevCommExitFlags::send indicates that the Host is requested to send a device request to the device.
- WhetherRmiDevCommExitFlags::wait indicates that the Host is requested to wait for a return a device response from the deviceto the RMM.
During communication between the RMM and a device which does not use SPDM:
- Whether theRmiDevCommExitFlags::wait indicates that the Host is requested to notify the RMM when a device transaction contains more than one (device request, device response) tuple is available.
The attributes of an RmiDevCommExit object are summarized in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| flags | 0x0 |
RmiDevCommExitFlags | Flags indicating action(s) which the Host is requested to perform |
| cache_offset | 0x8 |
UInt64 | If flags.cache is true, offset in the device response buffer to the start of data to be cached, in bytes |
| cache_len | 0x10 |
UInt64 | If flags.cache is true, amount of data to be cached, in bytes |
| protocol | 0x18 |
RmiDevCommProtocol | If flags.send is true, protocol to use |
| req_len | 0x20 |
UInt64 | If flags.send is true, amount of valid data in request buffer in bytes |
| timeout | 0x28 |
UInt64 | If flags.wait is true, amount of time to wait for device response in milliseconds |
9.2.5.2 Device communication enter data structure
An RmiDevCommEnter object is a data structure which is passed from the Host to the RMM during a device transaction.
The attributes of an RmiDevCommExitRmiDevCommEnter object tell the RMM the following:
- Whether the device reported an error.
- Whether the device response buffer contains a device response.
- The location of the device request buffer, into which the RMM can write a device request.
The attributes of an RmiDevCommEnter object are summarized in the following table.
D An RmiDevCommEnter object is a data structure which is passed from the Host to the RMM during a device transaction. I Whether the device reported an error. Whether the device response buffer contains a device response. The location of the device request buffer, into which the RMM can write a device request. The attributes of an RmiDevCommEnter object tell the RMM the following: D| Name | Byte offset | Type | Description |
|---|---|---|---|
| status | 0x0 |
RmiDevCommStatus | Status of device transaction |
| req_addr | 0x8 |
Address | Address of request buffer |
| resp_addr | 0x10 |
Address | Address of response buffer |
| resp_len | 0x18 |
UInt64 | Amount of valid data in response buffer in bytes |
The attributes of an RmiDevCommEnter object are summarized in the following tableSee also:
- Section 15.4.7
9.3 Physical device object
A Physical Device (PDEV) represents a communication channel between the RMM and a physical device, for example a PCIe device.
9.3.1 Physical device attributes
The attributes of a PDEV are summarized in the following table.
| Name | Type | Description |
|---|---|---|
| pdev_id | Bits64 | Device identifier |
| prot_config | RmmPdevProtConfig | Configuration of protection between system and device |
| segment_id | Bits16 | Segment identifier PCIe Segment identifier of the Root Port and endpoint. |
| root_id | Bits16 | Root Port identifier Physical PCIe routing identifier of the Root Port to which the endpoint is connected. |
| cert_id | UInt64 | Certificate identifier |
| rid_base | UInt64 | Base of requester ID range (inclusive) |
| rid_top | UInt64 | Top of requester ID range (exclusive) |
| hash_algo | RmmHashAlgorithm | Algorithm used to generate device digests |
| ncoh_sidide_sid | UInt64 | IDE stream ID used to secure non-coherent traffic |
| ncoh_num_addr_rangeiocoh_num_addr_range | UInt64 | Number of nonIO-coherent address ranges |
| ncoh_addr_rangeiocoh_addr_range | RmmAddressRange[16] | NonIO-coherent address range |
| coh_sidfcoh_num_addr_range | UInt64 | Selective IDE stream identifier coh_num_addr_range UInt64Number of fully-coherent address ranges |
| coh_addr_rangefcoh_addr_range | RmmAddressRange[4] | CoherentFully-coherent address range |
| aux | Address[32] | Addresses of auxiliary Granules |
| num_aux | UInt64 | Number of auxiliary Granules |
| state | RmmPdevState | Lifecycle state |
| comm_state | RmmDevCommState | Device communication state |
| num_vdevs | UInt64 | Number of VDEVs associated with this PDEV whose state is not VDEV_STOPPED |
The pdev.root_id and and pdev.cert_id attributes are ignored for platform-attested devices.
If pdev.3prot_config is PDEV_IOCOH_E2E_IDE or PDEV_FCOH_E2E_IDE then all of the following are true:
- The RMM checks that pdev.1ide_sid is not used by any other PDEV which is connected to the same Root Port.2
- The RMM configures an IDE selective stream with IDE selective stream ID pdev.ide_sid and IDE selective stream address ranges pdev.iocoh_addr_range.
State rules concerning Selective IDE and Link IDE streamsThe RMM checks that all entries in (pdev.rid_base, pdev.rid_top] are not used by any other PDEV within the same PCIe segment.
The RMM checks that all entries in pdev.iocoh_addr_range have the following properties:
- Fall within non-coherent IO ranges of the system address map.
- Not used by any other PDEV.
If pdev.prot_config is PDEV_FCOH_E2E_IDE or PDEV_FCOH_E2E_SYS then the RMM checks that all entries in pdev.fcoh_addr_range have the following properties:
- Fall within coherent IO ranges of the system address map.
- Not used by any other PDEV.
The following table summarises which PDEV attributes are valid for each value of pdev.prot_config.
| prot_config | Device type | ide_sid | (rid_base, rid_top] | iocoh_addr_range | fcoh_addr_range |
|---|---|---|---|---|---|
| PDEV_IOCOH_E2E_IDE | PCIe off-chip | Y | Y | Y | |
| PDEV_IOCOH_E2E_SYS | PCIe on-chip | Y | Y | ||
| PDEV_FCOH_E2E_IDE | CHI off-chip | Y | Y | Y | Y |
| PDEV_FCOH_E2E_SYS | CHI on-chip | Y | Y | Y |
9.3.2 Physical device lifecycle
9.3.2.1 States
The states of a PDEV are listed below.
| State | Description |
|---|---|
| PDEV_NEW | Initial state of the device. |
| PDEV_NEEDS_KEY | RMM needs device public key. |
| PDEV_HAS_KEY | RMM has device public key. |
| PDEV_READY | Secure connection between the RMM and the device has been established. Physical link between the device and memory is secured. Ready for creation of VDEV instances. |
| PDEV_IDE_RESETTING | The PDEV’s IDE link is being reset. |
| PDEV_COMMUNICATING | The RMM is communicating with the device. |
| PDEV_STOPPING | The RMM is communicating with the device to terminate the secure connection between the RMM and the device. |
| PDEV_STOPPED | Secure connection between the RMM and the device has been terminated. |
| PDEV_ERROR | Device has reported a fatal error. |
9.3.2.2 State transitions
Permitted PDEV Realm state transitions are shown in the following figure. Each arc is labeled with the events which can cause the corresponding state transition.
A transition from the pseudo-state NULL represents creation of a PDEV. A transition to the pseudo-state NULL represents destruction of a PDEV.
Permitted
9.3.2.2.1 State transitions for an independently-attested device
While a PDEV associated with an independently-attested device is in PDEV_NEW state, execution of RMI_PDEV_COMMUNICATE causes the RMM to fetch the device certificate. The RMM stores a digest of the device certificate for later retrieval by the Realm. The Host is expected to cache the device certificate for later retrieval by the Realm.
Once device certificate retrieval is complete, the PDEV moves to PDEV_NEEDS_KEY state.
While a PDEV associated with an independently-attested device is in PDEV_NEWPDEV_HAS_KEY state, execution of RMI_PDEV_COMMUNICATE causes the RMM to fetch the device certificate. The RMM stores a digest of the device certificate for later retrieval by the Realm. The Host is expected to cache the device certificate for later retrieval by the Realmperform secure SPDM session establishment and IDE key programming.
IOnce secure SPDM session establishment and IDE key programming is complete, the PDEV moves to PDEV_READY state.
While a PDEV associated with an independently-attested device is in PDEV_HAS_KEY state, execution of RMI_PDEV_COMMUNICATE causes the RMM to perform secure SPDM session establishment and IDE key programming.9.3.2.2.2 State transitions for a platform-attested device
While a PDEV associated with an platform-attested device is in PDEV_NEW state, execution of RMI_PDEV_COMMUNICATE causes the RMM to establish a communication channel with the device.
Once device certificate retrieval is complete, the PDEV moves to PDEV_READY state.
While a PDEV associated with an platform-attested device is in PDEV_NEW state, execution of RMI_PDEV_COMMUNICATE causes the RMM to establish a communication channel with the device.9.3.2.2.3 State transitions for devices which use IDE
While a PDEV is in PDEV_READY state, the Host can notify the RMM of an event relevant to the device by executing RMI_PDEV_NOTIFY.
If the return value is RMI_DEV_COMM_PENDING then the PDEV moves to PDEV_COMMUNICATING state.
While a PDEV is in PDEV_READY state, the Host can notify the RMM of an event relevant to the device by executing RMI_PDEV_NOTIFY.TheWhile a PDEV is in PDEV_READY state, if the device class is PCIe then the Host can request the device’s IDE link to be reset by executing RMI_PDEV_IDE_RESET.
The PDEV moves to PDEV_IDE_RESETTING state.
While a PDEV is in PDEV_READY state, if the device class is PCIe then the Host can request the device’s IDE link to be reset by executing RMI_PDEV_IDE_RESET.While a PDEV is in PDEV_IDE_RESETTING state, the Host can enact the “IDE reset” device transaction by executing RMI_PDEV_COMMUNICATE.
If the return value indicates that the device transaction is complete then the PDEV moves to PDEV_READY state.
While a PDEV is in PDEV_IDE_RESETTING state, the Host can enact the “IDE reset” device transaction by executing RMI_PDEV_COMMUNICATE.9.3.2.2.4 State transitions for all devices
While a PDEV is in PDEV_COMMUNICATING state, the Host can either:
- Transfer device requests and device responses by executing RMI_PDEV_COMMUNICATE. If the return value indicates that the device transaction is complete then the PDEV moves to PDEV_READY state.
- Abort the device transaction by executing RMI_PDEV_ABORT. On successful execution of this command, the PDEV moves to PDEV_READY state.
On execution of RMI_PDEV_COMMUNICATE, if the RMM detects a fatal error (such as an unexpected response or a protocol error) then the PDEV moves to PDEV_ERROR state.
TheWhile a PDEV is in any of the following state, the Host can request the RMM to stop the device by executing RMI_PDEV_STOP:
- PDEV_NEW
- PDEV_NEEDS_KEY
- PDEV_HAS_KEY
- PDEV_READY
- PDEV_IDE_RESETTING
- PDEV_ERROR
The PDEV moves to PDEV_STOPPING state.
PDEV_NEW PDEV_NEEDS_KEY PDEV_HAS_KEY PDEV_READY PDEV_IDE_RESETTING PDEV_ERROR While a PDEV is in any of the following state, the Host can request the RMM to stop the device by executing RMI_PDEV_STOP:While a PDEV is in PDEV_STOPPING state, the Host can enact the “stop” device transaction by executing RMI_PDEV_COMMUNICATE.
If the return value indicates that the device transaction is complete then the PDEV moves to PDEV_STOPPED state.
While a PDEV is in PDEV_STOPPING state, the Host can enact the “stop” device transaction by executing RMI_PDEV_COMMUNICATE.While a PDEV is in PDEV_STOPPING state, if the device fails to respond or reports an error then the Host can call RMI_PDEV_COMMUNICATE, passing RMI_DEV_COMM_ERROR.
On successful execution of this command, the PDEV moves to PDEV_STOPPED state.
While a PDEV is in PDEV_STOPPING state, if the device fails to respond or reports an error then the Host can call RMI_PDEV_COMMUNICATE, passing RMI_DEV_COMM_ERROR.While a PDEV is in PDEV_STOPPED state, the Host can reclaim resources by executing RMI_PDEV_DESTROY.
This command will fail if the PDEV is associated with any VDEVs.
While a PDEV is in PDEV_STOPPED state, the Host can reclaim resources by executing RMI_PDEV_DESTROY.Permitted PDEV state transitions are shown in the following table. The rightmost column lists the events which can cause the corresponding state transition.
A transition from the pseudo-state NULL represents creation of a PDEV object. A transition to the pseudo-state NULL represents destruction of a PDEV object.
| From state | To state | Events |
|---|---|---|
| NULL | PDEV_NEW | RMI_PDEV_CREATE |
| PDEV_NEW | NULL | RMI_PDEV_DESTROY |
| PDEV_NEW | PDEV_NEW | |
| PDEV_NEW | PDEV_NEEDS_KEY | RMI_PDEV_COMMUNICATE |
| PDEV_NEEDS_KEY | PDEV_HAS_KEY | RMI_PDEV_SET_PUBKEY |
| PDEV_HAS_KEY | PDEV_HAS_KEY | |
| PDEV_HAS_KEY | PDEV_READY | RMI_PDEV_COMMUNICATE |
| PDEV_READY | PDEV_COMMUNICATING | RMI_PDEV_NOTIFY |
| PDEV_COMMUNICATING | PDEV_COMMUNICATING | RMI_PDEV_COMMUNICATE |
| PDEV_COMMUNICATING | PDEV_READY | |
| PDEV_READY | PDEV_IDE_RESETTING | RMI_PDEV_IDE_RESET |
| PDEV_IDE_RESETTING | PDEV_READY | RMI_PDEV_COMMUNICATE |
| PDEV_NEW | PDEV_STOPPING | RMI_PDEV_STOP |
| PDEV_NEEDS_KEY | PDEV_STOPPING | RMI_PDEV_STOP |
| PDEV_HAS_KEY | PDEV_STOPPING | RMI_PDEV_STOP |
| PDEV_READY | PDEV_STOPPING | RMI_PDEV_STOP |
| PDEV_IDE_RESETTING | PDEV_STOPPING | RMI_PDEV_STOP |
| PDEV_ERROR | PDEV_STOPPING | RMI_PDEV_STOP |
| PDEV_STOPPING | PDEV_STOPPED | RMI_PDEV_COMMUNICATE |
| PDEV_STOPPED | NULL | RMI_PDEV_DESTROY |
See also:
See also:
9.3.3 Physical device flows
9.3.3.1 Physical device setup flow
Setup of a PDEV is illustrated in the following sequence diagram.
Setup of aMapping of the PDEV setup flow onto SPDM and IDE communication with a TDISP PCIe device is illustrated in the following sequence diagram.
I
Mapping of the PDEVIDE setup flow onto SPDM and IDE communication with a for a TDISP PCIe device is illustrated in the following sequence diagram.
I
See also:
9.4 Virtual device object
A virtual device (VDEV) represents the binding between a device function and a Realm.
9.4.1 Virtual device attributes
The attributes of a VDEV are summarized in the following table.
| Name | Type | Description |
|---|---|---|
| vdev_id | Bits64 | Virtual device identifier |
| tdi_id | Bits64 | TDI identifier |
| inst_id | UInt64 | Instance identifier |
| pdev | Address | PA of parent PDEV |
| realm | Address | PA of RD of Realm which owns this REC |
| state | RmmVdevState | Lifecycle state |
| comm_state | RmmDevCommState | Device communication state |
| aux | Address[32] | Addresses of auxiliary Granules |
| num_aux | UInt64 | Number of auxiliary Granules |
A Device identifier is a value which uniquely identifies a VDEV on a system, and is agreed between the Host and the Realm to which the VDEV is assigned.
The choice of device identifier depends upon the interface provided by the Host to the Realm. For example, if the Host provides a PCIe interface, then identifier is a PCIe (bus, device, function) tuple.
The Host provides the device identifier when executing RMI_VDEV_CREATE.
The Realm provides the device identifier when executing any RSI_RDEV command.
See also:
- Section 15.3.51
9.4.2 Virtual device invariants
Providing a tdi_id which is already used by another VDEV within the same segment causes RMI_VDEV_CREATE to fail.
The RMM can track usage of tdi_id values within a segment by using SW_RESERVED bits in the SMMU Stream Table Entry.
Providing a tdi_id which is outside the RID range of the parent PDEV causes RMI_VDEV_CREATE to fail.
9.4.3 Virtual device lifecycle
9.4.3.1 States
The states of a VDEV are listed below.
| State | Description |
|---|---|
| VDEV_READY | No device transaction is associated with the VDEV. |
| VDEV_COMMUNICATING | The RMM is communicating with the VDEV. |
| VDEV_STOPPING | The RMM is communicating with the VDEV to stop the device interface. |
| VDEV_STOPPED | Device interface is stopped. |
| VDEV_ERROR | Device interface has reported a fatal error. |
9.4.3.2 State transitions
Permitted VDEV state transitions are shown in the following figure. Each arc is labeled with the events which can cause the corresponding state transition.
A transition from the pseudo-state NULL represents creation of a VDEV. A transition to the pseudo-state NULL represents destruction of a VDEV.
While a VDEV is in VDEV_READY state, on a REC exit due to device communication, the VDEV moves to VDEV_COMMUNICATING state.
While a VDEV is in VDEV_COMMUNICATING state, the Host can either:
- Transfer device requests and device responses by executing RMI_VDEV_COMMUNICATE. If the return value indicates that the device transaction is complete then the VDEV moves to VDEV_READY state.
- Abort the device transaction by executing RMI_VDEV_ABORT. On successful execution of this command, the VDEV moves to VDEV_ERROR state.
On execution of RMI_VDEV_COMMUNICATE, if the RMM detects a fatal error (such as an unexpected response or a protocol error) then the VDEV moves to VDEV_ERROR state.
While a VDEV is in VDEV_READY state or VDEV_ERROR state, the Host can request the RMM to stop the device by executing RMI_VDEV_STOP.
If the return value is RMI_DEV_COMM_PENDING then the VDEV moves to VDEV_STOPPING state.
While a VDEV is in VDEV_STOPPING state, the Host can enact the “stop” device transaction by executing RMI_VDEV_COMMUNICATE.
If the return value indicates that the device transaction is complete then the VDEV moves to VDEV_STOPPED state.
While a VDEV is in VDEV_STOPPING state, if the device fails to respond or reports an error then the Host can call RMI_VDEV_COMMUNICATE, passing RMI_DEV_COMM_ERROR.
On successful execution of this command, the VDEV moves to VDEV_STOPPED state.
While a VDEV is in VDEV_STOPPED state, the Host can reclaim resources by executing RMI_VDEV_DESTROY.
Permitted VDEV state transitions are shown in the following figuretable. Each arc is labeled withThe rightmost column lists the events which can cause the corresponding state transition.
IWhile a VDEV is in VDEV_READY state, on a REC exit due to device communication, the VDEV moves to VDEV_COMMUNICATING state. I Transfer device requests and device responses by executing RMI_VDEV_COMMUNICATE. If the return value indicates that the device transaction is complete then the VDEV moves to VDEV_READY state. Abort the device transaction by executing RMI_VDEV_ABORT. On successful execution of this command, the VDEV moves to VDEV_READY state. While a VDEV is in VDEV_COMMUNICATING state, the Host can either: I On execution of RMI_VDEV_COMMUNICATE, if the RMM detects a fatal error (such as an unexpected response or a protocol error) then the VDEV moves to VDEV_ERROR state. I If the return value is RMI_DEV_COMM_PENDING then the VDEV moves to VDEV_STOPPING state. While a VDEV is in VDEV_READY state or VDEV_ERROR state, the Host can request the RMM to stop the device by executing RMI_VDEV_STOP. I If the return value indicates that the device transaction is complete then the VDEV moves to VDEV_STOPPED state. While a VDEV is in VDEV_STOPPING state, the Host can enact the “stop” device transaction by executing RMI_VDEV_COMMUNICATE. I On successful execution of this command, the VDEV moves to VDEV_STOPPED state. While a VDEV is in VDEV_STOPPING state, if the device fails to respond or reports an error then the Host can call RMI_VDEV_COMMUNICATE, passing RMI_DEV_COMM_ERROR. I While a VDEV is in VDEV_STOPPED state, the Host can reclaim resources by executing RMI_VDEV_DESTROY. I Permitted VDEV state transitions are shown in the following table. The rightmost column lists the events which can cause the corresponding stateA transition. A transition from the pseudo-state NULL represents creation of a VDEV object. A transition to the pseudo-state NULL represents destruction of a VDEV object.
| From state | To state | Events |
|---|---|---|
| NULL | VDEV_READY | RMI_VDEV_CREATE |
| VDEV_READY | VDEV_COMMUNICATING | REC exit due to device communication |
| VDEV_READY | VDEV_STOPPING | RMI_VDEV_STOP |
| VDEV_COMMUNICATING | VDEV_COMMUNICATING | RMI_VDEV_COMMUNICATE |
| VDEV_COMMUNICATING | VDEV_READYVDEV_ERROR | RMI_VDEV_ABORT |
| VDEV_ERROR | VDEV_STOPPING | RMI_VDEV_STOP |
| VDEV_STOPPING | VDEV_STOPPING | RMI_VDEV_COMMUNICATE |
| VDEV_STOPPING | VDEV_STOPPED | RMI_VDEV_COMMUNICATE |
| VDEV_STOPPED | NULL | RMI_VDEV_DESTROY |
See also:
- Section 4.3.11
9.4.4 Virtual device flows
9.4.4.1 Virtual device teardown flow
Teardown of a VDEV is illustrated in the following sequence diagram.
9.5 Realm management of an assigned device interface
This section describes interaction between a Realm and the RMM to manage an RDEV.
9.5.1 Interruptible Realm device operations
The following are interruptible Realm device operations:
- Requesting digests of device attestation evidence
- Requesting a device interface report
- Requesting device measurements
- Locking a device interface
- Starting a device interface
- Stopping a device interface
Interruptible Realm device operation are:
- Initiated by the Realm executing RSI commands
- Enacted via a REC exit due to device communication, and by subsequent Host calls to RMI_VDEV_COMMUNICATE.
The Realm programming model for interruptible Realm device operation consists of two phases:
The Realm initiates the operation by executing an RSI command. Successful execution of this command causes the RDEV to transition to a busy state.
The Realm executes RSI_RDEV_CONTINUE in a loop, until the result is not RSI_INCOMPLETE.
The following pseudocode illustrates this programming model, using RSI_RDEV_GET_INTERFACE_REPORT as an example.
int get_interface_report(...)
{
int ret;
ret = RSI_RDEV_GET_INTERFACE_REPORT(dev_id, ...);
if (ret) {
return ret;
}
do {
ret = RSI_RDEV_CONTINUE(dev_id);
} while (ret == RSI_INCOMPLETE);
return ret;
}Once an interruptible Realm device operation has been initiated by the Realm, it must either be:
- Completed by the Realm, via execution of RSI_RDEV_CONTINUE and subsequent calls by the Host to RMI_VDEV_COMMUNICATE, or
- Aborted by the Host, via execution of RMI_VDEV_ABORT.
If the Realm wishes to abort an interruptible Realm device operation, it must request the Host to do so.
Completed by the Realm, via execution of RSI_RDEV_CONTINUE and subsequent calls by the Host to RMI_VDEV_COMMUNICATE, or Aborted by the Host, via execution of RMI_VDEV_ABORT. Once an interruptible Realm device operation has been initiated by the Realm, it must either be:The set of commands which can initiate an interruptible Realm device operation are as follows:
- RSI_RDEV_GET_INTERFACE_REPORT
- RSI_RDEV_GET_MEASUREMENTS
- RSI_RDEV_LOCK
- RSI_RDEV_START
- RSI_RDEV_STOP
See also:
9.5.2 Realm retrieval of device attestation evidence
A Realm is expected to retrieve cached device attestation evidence from the Host via an RSI_HOST_CALL interface. Details of this interface are out of scope of this specification.
A Realm can retrieve digests of cached device attestation evidence from the RMM by executing the RSI_RDEV_GET_INFO command.
9.5.3 Realm validation of device memory mappings
A Realm device interface report describes the memory regions of the device. Each device memory region has the following attributes in the report:
PA base address of the region.
This is obfuscated by addition of a random offset value to the system physical address. The offset value is known to the RMM.
Size of the region.
Whether the mapping is private or shared.
Whether the output address of the mapping is within the system coherent memory space.
A Realm can validate by execution of RSI_RDEV_VALIDATE_MAPPING that each MMIO region in the Realm device interface report has been correctly mapped into the Realm’s Protected IPA space.
Execution of RSI_RDEV_VALIDATE_MAPPING initiates a RIPAS change request. On execution of RSI_RDEV_VALIDATE_MAPPING, the RMM records the PA base address of the region and the flags provided by the Realm in the REC. On subsequent execution of RMI_RTT_SET_RIPAS, the RMM validates that the contents of the target RTTE are compatible with the PA base address of the region and the flags provided by the Realm. If this validation passes then the RMM sets the RIPAS of the RTTE to DEV.
The RTTE attributes checked by RMI_RTT_SET_RIPAS, when the target RIPAS is RIPAS_DEV, are as follows:
- The IPA to PA mapping is consistent with the PA base address of the region provided by the Realm.
- The value of the GPT entry for the PA is consistent with the “shared” flag provided by the Realm.
- The memory attributes are consistent with the value of the “coh” flag provided by the Realm.
- The system memory space (coherent or non-coherent) of the PA is consistent with the “coh” flag provided by the Realm.
Creation and validation of device memory mappings is illustrated in the following sequence diagram.
9.5.4 Realm device attributes
The attributes of an RDEV are summarized in the following table.
| Name | Type | Description |
|---|---|---|
| state | RmmRdevState | Lifecycle state |
| operation | RmmRdevOperation | Operation being performed by the RDEV |
| vdev_ptr | Address | PA of VDEV associated with this RDEV |
9.5.5 Realm device lifecycle
9.5.5.1 States
The states of a RDEV are listed below.
| State | Description |
|---|---|
| RDEV_NEW | Device interface is unlocked. |
| RDEV_NEW_BUSY | Device interface is unlocked and is handling an interruptible Realm device operation. |
| RDEV_LOCKED | Device interface is locked. |
| RDEV_LOCKED_BUSY | Device interface is locked and is handling an interruptible Realm device operation. |
| RDEV_STARTED | Device interface is started. |
| RDEV_STARTED_BUSY | Device interface is started and is handling an interruptible Realm device operation. |
| RDEV_STOPPING | Device interface is stopping. |
| RDEV_STOPPED | Device interface is stopped. |
| RDEV_ERROR | Device interface has reported a fatal error. |
9.5.5.2 State transitions
Permitted RDEV Realm state transitions are shown in the following figure. Each arc is labeled with the events which can cause the corresponding state transition.
A transition from the pseudo-state NULL represents creation of an RDEV.
The Realm discovers an assigned PCIe TDI by probing PCIe config space. Arm expects that this will be emulated by the Host, via Unprotected IPA space.
While an RDEV is in RDEV_NEW state, the Realm can execute any of the following commands:
- RSI_RDEV_GET_MEASUREMENTS
- RSI_RDEV_LOCK
On successful execution of this command, the RDEV moves to RDEV_NEW_BUSY state and records the requested operation.
Permitting RSI_RDEV_GET_MEASUREMENTS while the RDEV is in RDEV_NEW state allows the Realm to perform the following sequence:
- Request a measurement of the initial firmware present in a device.
- Transition the device to RDEV_LOCKED.
- Upload new or additional firmware to the device.
- Verify that the firmware has been successfully uploaded, by requesting a new measurement from the device.
While an RDEV is in RDEV_NEW_BUSY state, the Realm can execute RSI_RDEV_CONTINUE.
Once the requested operation is complete:
- If the requested operation was RSI_RDEV_LOCK, the RDEV moves to RDEV_LOCKED state.
- Otherwise the RDEV moves to RDEV_NEW state.
While an RDEV is in RDEV_LOCKED state, the Realm can execute any of the following commands:
- RSI_RDEV_GET_INTERFACE_REPORT
- RSI_RDEV_GET_MEASUREMENTS
- RSI_RDEV_START
On successful execution of this command, the RDEV moves to RDEV_LOCKED_BUSY state and records the requested operation.
While an RDEV is in RDEV_LOCKED_BUSY state, the Realm can execute RSI_RDEV_CONTINUE.
Once the requested operation is complete:
- If the requested operation was RSI_RDEV_START, the RDEV moves to RDEV_STARTED state.
- Otherwise the RDEV moves to RDEV_LOCKED state.
While an RDEV is in RDEV_STARTED state, the Realm can execute any of the following commands:
- RSI_RDEV_GET_INTERFACE_REPORT
- RSI_RDEV_GET_MEASUREMENTS
On successful execution of this command, the RDEV moves to RDEV_STARTED_BUSY state and records the requested operation.
While an RDEV is in RDEV_STARTED_BUSY state, the Realm can execute RSI_RDEV_CONTINUE.
Once the requested operation is complete, the RDEV moves to RDEV_STARTED state.
On execution of RSI_RDEV_CONTINUE, if the RMM detects a fatal error (such as an unexpected response or a protocol error) then the RDEV moves to RDEV_ERROR state.
While an RDEV is in any state, the Realm can execute RSI_RDEV_STOP.
On successful execution of this command the RDEV moves to RDEV_STOPPING state.
Following successful execution of this command, accesses from the device to Realm memory are blocked.
While an RDEV is in RDEV_STOPPING state, the Realm can execute RSI_RDEV_CONTINUE.
Once the requested operation is complete, the RDEV moves to RDEV_STOPPED state.
Permitted RDEV Realm state transitions are shown in the following figure table. Each arc is labeled with The rightmost column lists the events which can cause the corresponding state transition.
I The Realm discovers an assigned PCIe TDI by probing PCIe config space. Arm expects that this will be emulated by the Host, via Unprotected IPA space. I On successful execution of this command, the RDEV moves to RDEV_NEW_BUSY state and records the requested operation. RSI_RDEV_GET_MEASUREMENTS RSI_RDEV_LOCK While an RDEV is in RDEV_NEW state, the Realm can execute any of the following commands: X Request a measurement of the initial firmware present in a device. Transition the device to RDEV_LOCKED. Upload new or additional firmware to the device. Verify that the firmware has been successfully uploaded, by requesting a new measurement from the device. Permitting RSI_RDEV_GET_MEASUREMENTS while the RDEV is in RDEV_NEW state allows the Realm to perform the following sequence: I If the requested operation was RSI_RDEV_LOCK, the RDEV moves to RDEV_LOCKED state. Otherwise the RDEV moves to RDEV_NEW state. Once the requested operation is complete: While an RDEV is in RDEV_NEW_BUSY state, the Realm can execute RSI_RDEV_CONTINUE. I On successful execution of this command, the RDEV moves to RDEV_LOCKED_BUSY state and records the requested operation. RSI_RDEV_GET_INTERFACE_REPORT RSI_RDEV_GET_MEASUREMENTS RSI_RDEV_START While an RDEV is in RDEV_LOCKED state, the Realm can execute any of the following commands: I If the requested operation was RSI_RDEV_START, the RDEV moves to RDEV_STARTED state. Otherwise the RDEV moves to RDEV_LOCKED state. Once the requested operation is complete: While an RDEV is in RDEV_LOCKED_BUSY state, the Realm can execute RSI_RDEV_CONTINUE. I On successful execution of this command, the RDEV moves to RDEV_STARTED_BUSY state and records the requested operation. RSI_RDEV_GET_INTERFACE_REPORT RSI_RDEV_GET_MEASUREMENTS While an RDEV is in RDEV_STARTED state, the Realm can execute any of the following commands: I Once the requested operation is complete, the RDEV moves to RDEV_STARTED state. While an RDEV is in RDEV_STARTED_BUSY state, the Realm can execute RSI_RDEV_CONTINUE. I On execution of RSI_RDEV_CONTINUE, if the RMM detects a fatal error (such as an unexpected response or a protocol error) then the RDEV moves to RDEV_ERROR state. I Following successful execution of this command, accesses from the device to Realm memory are blocked. On successful execution of this command the RDEV moves to RDEV_STOPPING state. While an RDEV is in any state, the Realm can execute RSI_RDEV_STOP. I Once the requested operation is complete, the RDEV moves to RDEV_STOPPED state. While an RDEV is in RDEV_STOPPING state, the Realm can execute RSI_RDEV_CONTINUE. I Permitted RDEV state transitions are shown in the following table. The rightmost column lists the events which can cause the corresponding state transition.| From state | To state | Events |
|---|---|---|
| RDEV_NEW | RDEV_NEW_BUSY | |
| RDEV_NEW_BUSY | RDEV_NEW_BUSY | RSI_RDEV_CONTINUE |
| RDEV_NEW_BUSY | RDEV_LOCKED | RSI_RDEV_CONTINUE |
| RDEV_LOCKED | RDEV_LOCKED_BUSY | |
| RDEV_LOCKED_BUSY | RDEV_LOCKED_BUSY | RSI_RDEV_CONTINUE |
| RDEV_LOCKED_BUSY | RDEV_STARTED | RSI_RDEV_CONTINUE |
| RDEV_STARTED | RDEV_STARTED_BUSY | |
| RDEV_STARTED_BUSY | RDEV_STARTED_BUSY | RSI_RDEV_CONTINUE |
| RDEV_NEW | RDEV_STOPPING | RSI_RDEV_STOP |
| RDEV_LOCKED | RDEV_STOPPING | RSI_RDEV_STOP |
| RDEV_STARTED | RDEV_STOPPING | RSI_RDEV_STOP |
| RDEV_NEW | RDEV_ERROR |
Host is stopping device interface |
| RDEV_NEW_BUSY | RDEV_ERROR |
Host is stopping device interface |
| RDEV_NEW_BUSY | RDEV_NEW |
Host has stopped device interface |
| RDEV_LOCKED | RDEV_ERROR |
Host is stopping device interface |
| RDEV_LOCKED_BUSY | RDEV_ERROR |
Host is stopping device interface |
| RDEV_LOCKED_BUSY | RDEV_NEW |
Host has stopped device interface |
| RDEV_STARTED | RDEV_ERROR |
Host is stopping device interface |
| RDEV_STARTED_BUSY | RDEV_ERROR |
Host is stopping device interface |
| RDEV_STARTED_BUSY | RDEV_NEW |
Host has stopped device interface |
| RDEV_ERROR | RDEV_STOPPING | RSI_RDEV_STOP |
| RDEV_STOPPING | RDEV_STOPPING | RSI_RDEV_CONTINUE |
| RDEV_STOPPING | RDEV_NEW | RSI_RDEV_CONTINUE |
See also:
9.5.5.3 Relationship between RDEV state and TDISP TDI state
The lifecycle of an RDEV closely resembles the lifecycle of a TDISP TDI. There cannot exist a direct mapping between the two, because changes in TDI state (for example due to Host action) may not be immediately observed by either the RMM or the Realm. However, the two states are sufficiently closely coupled to provide the Realm with important guarantees regarding the TDI state.
On transition of an RDEV to RDEV_LOCKED state, the corresponding TDI transitions to CONFIG_LOCKED state.
On transition of an RDEV to RDEV_STARTED state, the corresponding TDI transitions to RUN state.
On detection by the RMM that a TDI is in ERROR state, the corresponding RDEV transitions to RDEV_ERROR state.
See also:
9.5.5.4 Relationship between RDEV state and SMMU enablement
When the state of an RDEV is RDEV_STARTED, the SMMU permits traffic from the device to the Realm’s Protected IPA space. When the state of an RDEV is not RDEV_STARTED, the SMMU blocks traffic from the device to the Realm’s Protected IPA space.
9.5.6 Realm device flows
9.5.6.1 Realm device setup flow
Setup of an RDEV is illustrated in the following sequence diagram.
9.6 Device access to a Protected IPA
Device access to a Protected IPA follows the same rules as Realm data access to a Protected IPA.
See also:
- Section 5.2.3
10 Planes
This section describes how a Realm can be divided into multiple mutually isolated execution environments, called Planes.
Decide whether this section should be:
- Moved to the Concepts chapter, alongside the Realm section.
- Left in this position, on the grounds that, like Realm device assignment, Planes is an optional feature.
10.1 Planes overview
The following aspects and implications of Planes will be described in a future release of this specification:
- Access from Pn to a device assigned to the Realm
A Realm contains:
- a single primary Plane
- zero or more auxiliary Planes.
A Realm with a non-zero number of auxiliary Planes is said to contain multiple Planes.
a single primary Plane zero or more auxiliary Planes. A Realm contains:The number of auxiliary Planes is specified by the Host at Realm creation.
Planes within a Realm are identified using a zero-based Plane index.
The Plane index of the primary Plane is zero.
When referring to the primary Plane of a Realm, this specification uses the term Plane 0, or P0.
When referring to any auxiliary Plane, this specification uses the term Pn.
When referring to the primary Plane of a Realm, this specification uses the term Plane 0, or P0.All Planes within a Realm share a single IPA space.
Stage 2 memory access permissions for a given IPA can differ between Planes.
All Planes within a Realm share a single IPA space.Each Plane has a VMID which is unique both within the owning Realm and among all Realms.
A Realm with multiple Planes may either have:
- An RTT tree per Plane, or
- A single RTT tree, with per-Plane access permissions being managed indirectly.
On REC exit due to Data Abort, Instruction Abort or RTT request, the index of the RTT tree used by the exited Plane is provided to the Host.
This allows the Host to know which RTT tree must be modified in order to service a fault.
On REC exit due to Data Abort, Instruction Abort or RTT request, the index of the RTT tree used by the exited Plane is provided to the Host.A given VPE executes in one Plane at a time.
This is referred to as the active Plane of the VPE.
A given VPE executes in one Plane at a time.The following capabilities are available only to P0:
- Change the active Plane of the current VPE
- Read and write register state of other Planes in the current VPE
- Configure and take traps from other Planes in the current VPE
- Control delivery of virtual interrupts to other Planes in the current VPE Execute RSI commands
10.2 Planes exception model
Decide whether this section should be integrated into the main Realm exception model chapter.
10.2.1 Plane exception model overview
A Plane entry is a transition from P0 to Pn, due to execution of RSI_PLANE_ENTER.
P0 provides the index of the target Plane (Pn) as an input to the RSI_PLANE_ENTER command.
A Plane exit is return to P0 from an execution of RSI_PLANE_ENTER which caused a Plane entry.
A PlaneRun object is a data structure used to pass values between the RMM and P0 on Plane entry and on Plane exit.
A PlaneRun object is stored in Realm memory.
Between a Plane entry and a Plane exit, a REC exit and REC entry may occur.
As an example:
Running in REC A, P0 executes RSI_PLANE_ENTER, passing target Plane index 1.
This causes a Realm exit to the RMM, followed by a Realm entry to P1, within REC A.
Running in REC A, P1 accesses an IPA which is not mapped (HIPAS = UNASSIGNED, RIPAS = RAM).
This causes a REC exit to the Host.
The Host executes RMI_REC_ENTER, passing the address of REC A.
This causes the RMM to return to P1 within REC A.
Running in REC A, P1 accesses an IPA whose RIPAS is EMPTY.
This causes a Plane exit to P0.
Following a REC exit from P0, on the next entry to the same REC, control returns to P0.
Following a REC exit from Pn, on the next entry to the same REC, the Host determines whether:
Control returns to Pn. This is the default behaviour.
A Plane exit occurs, returning control to P0. This can be triggered for example due to the Host injecting a virtual interrupt into the REC.
10.2.2 Plane entry
An RsiPlaneEnter object is a data structure used to pass values from P0 to the RMM on Plane entry.
An RsiPlaneEnter object is stored in the RsiPlaneRun object which is passed by P0 as an input to the RSI_PLANE_ENTER command.
In this chapter, both plane_enter and “the RsiPlaneEnter
object” refer to the RsiPlaneEnter object which is provided to the
RSI_PLANE_ENTER command.
On Plane entry, execution state is restored from the RsiPlaneEnter object to the PE.
An RsiPlaneEnter object contains attributes which are used to manage Pn virtual interrupts.
The attributes of an RsiPlaneEnter object are summarized in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| flags | 0x0 |
RsiPlaneEnterFlags | Flags |
| pc | 0x8 |
Bits64 | Program counter |
| gprs[31] | 0x100 |
Bits64 | Registers |
| gicv3_hcr | 0x200 |
Bits64 | GICv3 Hypervisor Control Register value |
| gicv3_lrs[16] | 0x208 |
Bits64 | GICv3 List Register values |
10.2.3 Plane exit
An RsiPlaneExit object is a data structure used to pass values from the RMM to P0 on Plane exit.
An RsiPlaneExit object is stored in the RsiPlaneRun object which is passed by P0 as an input to the RSI_PLANE_ENTER command.
In this chapter, both plane_exit and “the RsiPlaneExit
object” refer to the RsiPlaneExit object which is provided to the
RSI_PLANE_ENTER command.
On Plane exit, execution state is saved from the PE to the RsiPlaneExit object.
The attributes of an RsiPlaneExit object are summarized in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| reason | 0x0 |
RsiPlaneExitReason | Exit reason |
| elr_el2 | 0x100 |
Bits64 | Exception Link Register |
| esr_el2 | 0x108 |
Bits64 | Exception Syndrome Register |
| far_el2 | 0x110 |
Bits64 | Fault Address Register |
| hpfar_el2 | 0x118 |
Bits64 | Hypervisor IPA Fault Address register |
| gprs[31] | 0x200 |
Bits64 | Registers |
| gicv3_hcr | 0x300 |
Bits64 | GICv3 Hypervisor Control Register value |
| gicv3_lrs[16] | 0x308 |
Bits64 | GICv3 List Register values |
| gicv3_misr | 0x388 |
Bits64 | GICv3 Maintenance Interrupt State Register value |
| gicv3_vmcr | 0x390 |
Bits64 | GICv3 Virtual Machine Control Register value |
| cntp_ctl | 0x400 |
Bits64 | Counter-timer Physical Timer Control Register value |
| cntp_cval | 0x408 |
Bits64 | Counter-timer Physical Timer CompareValue Register value |
| cntv_ctl | 0x410 |
Bits64 | Counter-timer Virtual Timer Control Register value |
| cntv_cval | 0x418 |
Bits64 | Counter-timer Virtual Timer CompareValue Register value |
RsiPlaneExit uses architectural encodings (of ESR, FAR, HPFAR) which are normally observable only to EL2; however, the exit is taken to P0 at EL1. This is justified on the grounds that P0 exists essentially in order to allow part of the job of the hypervisor to be performed inside the Realm.
On Plane exit, all RsiPlaneExit fields are zero unless specified otherwise.
10.2.3.1 Plane exit due to synchronous exception
An exception due to any of the following in Pn causes a Plane exit due to Synchronous Exception:
Trapped WF* instruction execution
Data Abort at a Protected IPA
- Permission fault
- Access to an IPA whose RIPAS is EMPTY
Instruction Abort at a Protected IPA
- Permission fault
- Access to an IPA whose RIPAS is EMPTY
HVC instruction execution
RSI_HOST_CALL execution, if
plane_enter.flags.trap_hc == RSI_TRAPAny other SMC instruction execution
If plane_enter.flags.trap_hc == RSI_NO_TRAP then execution by Pn of RSI_HOST_CALL results in a RECOn Plane exit due to Host call.Synchronous Exception, all of the following are true:
Rplane_exit.exit_reasonis RSI_EXIT_SYNC.plane_exit.esr_el2contains the value ofESR_EL2at the time of the Realm exit.- If
plane_exit.esr_el2.ECindicates Data Abort from a lower Exception level and
plane_exit.esr_el2.ISV == 1thenplane_exit.far_el2contains the value ofFAR_EL2at the time of the Realm exit. - If
plane_exit.esr_el2.ECindicates Data Abort from a lower Exception level or Instruction Abort from a lower Exception level,plane_exit.hpfar_el2contains the value ofHPFAR_EL2at the time of the Realm exit.
See also:
- Section 4.3.9
10.2.4 REC exit from Pn
An exception due to any of the following in Pn cause a REC exit to the Host:
- The following Synchronous Exceptions:
- Access to an IPA whose RIPAS is DESTROYED
- Access to an IPA whose HIPAS is UNASSIGNED and whose RIPAS is not EMPTY
- Synchronous External Abort
- The following Asynchronous Exceptions:
- IRQ
- FIQ
- SError
- RSI_HOST_CALL execution, if
plane_enter.flags.trap_hc == RSI_NO_TRAP. In this case, the result is a REC exit due to Host call.
Any other exception during execution of Pn causes a Plane exit to P0.
10.2.5 Pn execution of HVC and SMC
On Plane exit due to execution by Pn of an HVC instruction, possible actions taken by P0 include the following:
- Emulate the instruction
- Forward the request to the Host using RSI_HOST_CALL
- Return SMCCC_NOT_SUPPORTED to Pn.
On Plane exit due to execution by Pn of an RSI command, possible actions taken by P0 include the following:
- Emulate the RSI command
- Return SMCCC_NOT_SUPPORTED to Pn.
10.2.6 Pn system registers
On Realm creation, all Pn EL0 and EL1 system register values take architecturally-defined reset values.
P0 can access Pn EL0 and EL1 system register values using the RSI_PLANE_REG_READ and RSI_PLANE_REG_WRITE commands.
10.3 Planes memory management
Decide whether this section should be integrated into the main Realm memory management chapter.
All Planes within a Realm have the same IPA size.
If a given IPA x is mapped to a given PA y in one Plane, x is not mapped to a different PA z in any other Plane within the Realm.
10.3.1 Auxiliary RTT
A Realm which is configured to have an RTT tree per Plane has one primary RTT tree and (number of auxiliary Planes) auxiliary RTT trees.
TheFor a Realm which is configured to have an RTT tree index of the primary RTT tree is zero. For a Realm which is configured to have an RTT tree per Plane, RTT trees are identified using a zero-based RTT tree index.
The RTT tree index of the primary RTT tree is zero.
For a Realm which is configured to have an RTT tree per Plane, the mapping from Plane index to RTT tree index is as follows:
| Plane index | RTT tree index |
|---|---|
| 0 | 1 |
| 1 | 2 |
| … | … |
| n-2 | n-1 |
| n-1 | 0 |
For a Realm with no auxiliary Planes, n == 1 and
therefore the index of the single Plane (0) maps to the index of the
single RTT tree (0).
Creation, destruction and folding of primary RTTs is independent of creation, destruction and folding of auxiliary RTTs for the same IPA range.
If a primary RTT entry is live and its state is not TABLE then the Host can create a mapping to the same output address in an auxiliary RTT by executing RMI_RTT_AUX_MAP_PROTECTED or RMI_RTT_AUX_MAP_UNPROTECTED.
An IPA is auxiliary-live if any of the entries identified by that IPA in auxiliary RTTs are live.
In a Realm which is configured to have an RTT tree per Plane, a given Unprotected IPA may be mapped to different output addresses in different Planes.
The absence of a rule which states that a given Unprotected IPA must map to the same output address in different Planes avoids the need for the RMM to manage reference counts for NS Granules.
If a Protected IPA is auxiliary-live then the corresponding entry in the primary RTT is live.
This invariant is preserved by blocking any actions which would make the primary RTT entry non-live, including the following:
- RMI_DATA_DESTROY
- RMI_DEV_MEM_UNMAP
- RMI_RTT_SET_RIPAS
If a Protectedan IPA is auxiliary-live then the corresponding entry in the primary RTT is liveits RIPAS cannot be changed.
IfSpecifying that RIPAS is invariant while an IPA is auxiliary-live then its RIPAS cannot be changed. X Specifying that RIPAS is invariant while an IPA is avoids an implementation of RMI_RTT_SET_RIPAS having to walk multiple auxiliary-live avoids an implementation of RMI_RTT_SET_RIPAS having to walk multiple auxiliary RTT trees.
See also:
10.3.2 Stage 2 access permissions
This section describes how Stage 2 access permissions (S2AP) are managed for Realm IPA space.
10.3.2.1 Stage 2 access permissions overview
The programming model for control of S2AP is based on indirection, as follows:
Each IPA has an S2AP base index.
- For a Protected IPA, the S2AP base index is fixed.
- For an Unprotected IPA, the S2AP base index is controlled by the Host via RMI commands.
The mapping from S2AP base index to S2AP base value is defined by this specification.
Each IPA has an S2AP overlay index.
- For a Protected IPA, the S2AP overlay index is controlled by P0, via RSI commands.
- For an Unprotected IPA, the S2AP overlay index is fixed.
Each { Plane, S2AP overlay index } tuple maps to an S2AP overlay value.
- For Pn, this mapping is controlled by P0 via RSI commands, subject to certain constraints imposed by the RMM.
- For P0, this mapping is architecturally fixed.
The S2AP which applies to an access from a given Plane to a given IPA are defined by the combination of the S2AP base value and the S2AP overlay value, following the rules for Stage 2 permission indirection in the Arm Architecture Reference Manual for A-Profile architecture [3].
The S2AP which applies to an access from P0 to a Protected IPA is architecturally fixed to RW+puX.
The S2AP which applies to an access from Pn to a Protected IPA is controlled by P0.
The S2AP which applies to an access from Pn to a Protected IPA can be different for each Pn within the Realm.
An access by Pn to a Protected IPA which violates S2AP causes a Plane exit taken to P0.
The S2AP which applies to a Realm access to an Unprotected IPA is controlled by the Host.
The S2AP which applies to a Realm access to an Unprotected IPA is the same for all Planes within the Realm.
A data access by Pn to an Unprotected IPA which violates S2AP causes a REC exit taken to the Host.
An instruction fetch by Pn to an Unprotected IPA causes a Plane exit taken to P0.
On a platform which implements FEAT_S2PIE and FEAT_S2POE, the RMM can utilise these architecture features to store per-Plane S2AP in a single RTT tree.
On a platform which does not implement these architecture features, a separate RTT tree is required for each Plane.
On a platform which implements FEAT_S2PIE and FEAT_S2POE, the RMM can utilise these architecture features to store per-Plane S2AP in a single RTT tree.10.3.2.2 Stage 2 access permissions for a Protected IPA
The S2AP overlay index of a Protected IPA is between 0 and 14.
S2AP overlay index 15 is RESERVED.
At Realm activation, S2AP overlay indices 0 to 14 map to S2AP overlay value RW+puX for P0.
At Realm activation, S2AP overlay indices 0 to 14 map to S2AP overlay value NoAccess for all Planes other than P0.
For each S2AP overlay index there is an associated lock bit which applies to S2AP overlay values for Planes other than P0.
- If the lock bit is LOCKED then the S2AP overlay values for all Planes are immutable.
- If the lock bit is UNLOCKED then the S2AP overlay values for Planes other than P0 can be changed by P0.
At Realm activation, S2AP overlay index 0 is LOCKED.
At Realm activation, S2AP overlay indices 1 to 14 are UNLOCKED.
At Realm activation, the S2AP overlay index of all Protected IPAs is 0.
The following table summarises the attributes of all S2AP overlay indices for Protected IPA space, at Realm activation.
| S2AP overlay index | P0 S2AP overlay value | Pn S2AP overlay values | Lock status for Pn S2AP overlay values |
|---|---|---|---|
| 0 | RW+puX | NoAccess | LOCKED |
| 1 to 14 | RW+puX | NoAccess | UNLOCKED |
The RSI_MEM_SET_PERM_INDEX command can be used by P0 to change the S2AP overlay index for a Protected IPA.
The RSI_MEM_SET_PERM_VALUE command can be used by P0 to change the mapping from a { Plane, S2AP overlay index } tuple to an S2AP overlay value.
10.3.2.3 Stage 2 access permissions for an Unprotected IPA
In this way, the RMM ensures that neither unprivileged execute permission (uX) nor privileged execute permission (pX) is observed onThe programming model for control by the Host of S2AP for Unprotected IPA space depends on the configuration of the Realm access to an Unprotected IPA.
If the Realm is configured to use an RTT tree per Plane then S2AP are specified directly, as follows:
The Host provides the RW field in the descriptor passed to RMI_RTT_MAP_UNPROTECTED to create the mapping in the primary RTT tree.
Execution of RMI_RTT_AUX_MAP_UNPROTECTED causes the RW and XN fields to be copied from the primary RTT tree into an auxiliary RTT tree.
The RMM enforces that the XN field of the descriptors in all RTT trees never grants execute permission.
If the Realm is configured to use a single RTT tree then then S2AP are specified indirectly as follows:
The Host provides an S2AP base index in the descriptor passed to RMI_RTT_MAP_UNPROTECTED.
The RMM configures the S2AP overlay index to provide a S2AP overlay value of RW.
The observed S2AP is defined by the combination of the S2AP base value and the S2AP overlay value, following the rules for Stage 2 permission indirection in the Arm Architecture Reference Manual for A-Profile architecture [3].
If theIn this way, the RMM ensures that neither unprivileged execute permission (uX) nor privileged execute permission (pX) is observed on Realm is configured to use a single RTT tree then then S2AP are specified indirectly as follows: The Host provides the RW field in the descriptor passed to RMI_RTT_MAP_UNPROTECTED to create the mapping in the primary RTT treeaccess to an Unprotected IPA.
Execution of RMI_RTT_AUX_MAP_UNPROTECTED causes the RW and XN fields to be copied from the primary RTT tree into an auxiliary RTT tree. The RMM enforces that the XN field of the descriptors in all RTT trees never grants execute permission. If the Realm is configured to use an RTT tree per Plane then S2AP are specified directly, as follows: The programming model for control by the Host of S2AP for Unprotected IPA space depends on the configuration of the Realm.10.3.2.4 Stage 2 access permissions change
An S2AP change is a process via which the S2AP of a region of Protected IPA space is changed.
An S2AP change consists of actions taken both by P0 within the Realm and by the Host:
- P0 issues an S2AP change request by executing
RSI_MEM_SET_PERM_INDEX.
- The input values to this command include:
- The requested IPA range:
[base, top) - The requested S2AP overlay index
- A “cookie”, whose initial value is zero. Across successive calls to RSI_MEM_SET_PERM_INDEX, the cookie is used by the RMM to store an implementation defined value which tracks progress of the request.
- The requested IPA range:
- The RMM records these values in the REC, and then performs a REC exit due to S2AP change pending.
- The input values to this command include:
- In response, the Host executes zero or more RMI_RTT_SET_S2AP commands.
- If the requested RIPAS value was not EMPTY then at the next RMI_REC_ENTER the Host can optionally indicate that it rejects the S2AP change request.
The purpose of the cookie is to record the progress of the S2AP change request across multiple RTT trees. For a Realm which is configured to use a shared RTT tree, the RMM should return a cookie value of zero.
Rejection by the Host of an S2AP change request is intended to be used if the target IPA range extends beyond the agreed DRAM range for the Realm. In this situation, accepting the request may impose unplanned resource costs on the Host, by requiring allocation of additional RTTs.
The S2AP change process ensures that a Realm can always reliably determine the maximum S2AP which can be observed at the next access to any Protected IPA.
An S2AP change is applied by one or more calls to the RMI_RTT_SET_S2AP command.
The order in which the S2AP of Planes and pages within the target IPA range are changed during execution of RSI_MEM_SET_PERM_INDEX is implementation defined.
If the input arguments of RSI_MEM_SET_PERM_INDEX are modified by the caller during the loop, it is implementation defined whether the S2AP of Planes and pages within the target IPA range are changed.
The P0 programming model for changing S2AP is to call RSI_MEM_SET_PERM_INDEX in a loop until progress reaches the top of the target IPA range, as shown in the following pseudocode:
int realm_set_s2ap(unsigned long base, unsigned long top,
unsigned int index)
{
unsigned long new_base, response;
unsigned long cookie = 0, new_cookie;
int ret = RSI_SUCCESS;
while (base != top) {
ret = rsi_mem_set_perm_index(base, top, index, cookie,
&new_base, &response,
&new_cookie);
if (ret != RSI_SUCCESS) {
return ret;
}
if (response == RSI_REJECT) {
return RSI_ERROR_INPUT;
}
base = new_base;
cookie = new_cookie;
}
return RSI_SUCCESS;
}The Host programming model for handling an S2AP change request is to call RMI_RTT_SET_S2AP in a loop until progress reaches the top of the target IPA range, as shown in the following pseudocode:
int host_set_s2ap(unsigned long base, unsigned long top)
{
unsigned long out_top, index, rtt_tree;
int ret = RMI_SUCCESS;
while (base != top) {
ret = rmi_rtt_set_s2ap(rd, rec, base, top,
&out_top, &rtt_tree, &index);
if (ret == RMI_ERROR_RTT || ret == RMI_ERROR_AUX_RTT) {
create_rtt(ipa = out_top, level = index + 1, rtt_tree);
continue;
} else if (ret != RMI_SUCCESS) {
break;
}
base = out_top;
}
return ret;
}On REC entry following a REC exit due to S2AP change,
rec.s2ap_response is set to the value of
enter.flags.s2ap_response.
Otherwise,If all of the following are true then the output value of RSI_MEM_SET_PERM_INDEX indicates “Host accepted the request”. rejected the request”:
rec.s2ap_addris not equal torec.s2ap_top.rec.s2ap_responseis REJECT.
If all of the following are true thenOtherwise, the output value of RSI_MEM_SET_PERM_INDEX indicates “Host rejected the request”: accepted the request”.
See also:
10.3.2.5 Stage 2 access permissions reset due to Host action
Execution of RMI_RTT_DESTROY or RMI_RTT_AUX_DESTROY sets the S2AP overlay index of the target RTTE to 0.
The Host is permitted at any time to destroy an RTT. Destruction of an RTT causes the RMM to lose information about the S2AP for the IPA range described by that RTT. The S2AP are observable by the Realm only while the RIPAS is RAM. Therefore, this specification defines the value to which the S2AP overlay index must be reset on a RIPAS transition to RAM.
See also:
- Section 5.4
10.4 Planes interrupts
Decide whether this section should be integrated into the main Realm interrupts section.
On REC creation, the GIC owner for the REC is P0.
On Plane entry, P0 can transfer GIC ownership to the target Pn.
On Plane entry, if P0 transfer GIC ownership to the target Pn then the GIC state in RsiPlaneEnter is ignored. This means that the GIC state of the owner is preserved and is shared across GIC ownership changes between planes.
Allowing P0 to control which Plane is the GIC owner supports software usage models including the following:
P0 is the GIC owner, and P0 emulates a vGIC for Pn, similar to how the Host emulates a vGIC for the Realm.
P0 is a lightweight “Pn switcher”, which does not emulate a vGIC. GIC ownership is transferred to the Pn which contains the main Realm guest OS.
P0 can read the value of ICH_VTR_EL2 using the RSI_REALM_CONFIG command.
On Plane exit, P0 is the GIC owner. If GIC ownership transferswas transferred to Pn on Plane entry, it returns to P0 on Plane exit.
On Plane exit, Pn’s GIC state is exposed to P0 via the RsiPlaneExit object.
On REC entry the GIC state provided by the Host is assigned to the GIC owner.
On REC entry, if the values of enter.gicv3_lrs describe
one or more Pending interrupts and the most recent REC exit was from a
Plane which is not the GIC owner then control returns to P0. This
results in a Plane exit due to synchronous exception.
On REC entry, if theall of the following is true then control returns to P0, resulting in a Plane exit due to synchronous exception:
- The most recent REC exit was from Pn and the
- The most recent REC exit was not from the GIC owner
- The value of
ICH_MISR_EL2at the time of the REC exit was not zero then control returns to P0. This results in a Plane exit due to synchronous exception.
On REC exit, the Realm GIC state of the GIC owner Plane is reported to the Host.
10.5 Planes timers
Decide whether this section should be integrated into the main Realm timers section.
On REC exit from P0, the Realm EL1 timer state reported to the Host is P0’s EL1 timer state.
A Realm EL1 timer is active if it is enabled and unmasked.
On REC exit from Pn, for each of the EL1 virtual and physical timers, if any of the following is true then the timer state reported to the Host is Pn’s EL1 timer state:
- The Pn timer is active and the P0 timer is not active.
- Both Pn and P0 timers are active and the Pn timer deadline is earlier than the P0 timer deadline.
Otherwise, the timer state reported to the Host is P0’s EL1 timer state.
The Pn timer is active and the P0 timer is not active. Both Pn and P0 timers are active and the Pn timer deadline is earlier than the P0 timer deadline. On REC exit from Pn, for each of the EL1 virtual and physical timers, if any of the following is true then the timer state reported to the Host is Pn’s EL1 timer state:The following table summarises the timer state which is reported to the Host on REC exit.
| P0 active | Pn active | Earliest CVAL | Reported to Host |
|---|---|---|---|
| 0 | 0 | P0 | P0 |
| 0 | 0 | Pn | P0 |
| 0 | 1 | P0 | Pn |
| 0 | 1 | Pn | Pn |
| 1 | 0 | P0 | P0 |
| 1 | 0 | Pn | P0 |
| 1 | 1 | P0 | P0 |
| 1 | 1 | Pn | Pn |
On Plane exit, Pn’s EL1 timer state is exposed to P0 via the RsiPlaneExit object.
P0 software should check the Realm EL1 timer state on every return
from RSI_PLANE_ENTER and update virtual interrupt state accordingly.
This is true regardless of the value of exit.exit_reason:
even if the return occurred for a reason unrelated to timers (for
example, a Plane exit due to Data Abort), the Realm EL1 timer state
should be checked.
On Plane entry, the RMM may mask the hardware timer signal, following the same logic as for REC entry.
Management of EL1 timer state for a Realm with multiple Planes can be implemented by multiplexing the following into the EL2 hardware timers:
- P0’s EL1 timers
- The Host’s EL2 timers
11 Realm memory encryption
This section describes encryption of physical memory which is accessible via Realm PAS. This encryption is transparent to Realm software, but has an impact on the security posture of a Realm.
A Memory Encryption Context (MEC) is an encryption regime used to protect the memory owned by a Realm.
The memory protected by a Realm’s MEC includes all memory which can be accessed by the Realm, and the RTTs which are owned by the Realm.
Other Granules owned by the Realm, such as REC and RD, are protected with the RMM’s MEC.
A Memory Encryption Context Identifier (MECID) is a handle which is used to identify a MEC.
The highest MECID value which the Host is permitted to pass via an RMI command is reported by the RMI_FEATURES command in RmiFeatureRegister1::MAX_MECID.
A valid MECID is a MECID in the range
[0, MAX_MECID].
On a platform which does not implement FEAT_MEC, MAX_MECID is zero.
On a platform which implements FEAT_MEC, MAX_MECID is expected to be computed as follows:
- Determine the minimum MECID width supported across all system components capable of initiating Realm PAS transactions.
- Determine the number of MECIDs which the platform needs to reserve for its own use. This is expected to be at least one, for protection of the RMM’s memory.
- Return
MAX_MECID = (2 ^ MECID_WIDTH) - (NUM_RESERVED_MECIDS + 1)
A MEC has a MEC policy.
The MEC policy values are shown in the following table.
| Name | Description |
|---|---|
| MEC_POLICY_PRIVATE | The MEC protects memory owned by a single Realm. A MEC with this policy may be referred to as a Private MEC. |
| MEC_POLICY_SHARED | The MEC protects memory owned by multiple Realms. A MEC with this policy may be referred to as a Shared MEC. |
TheA MEC policyhas a MEC state.
The MEC state values are shown in the following table.
A MEC has a MEC policy. D| Name | Description |
|---|---|
| MEC_STATE_PRIVATE_ASSIGNED | A Private MEC which is assigned to a Realm. |
| MEC_STATE_PRIVATE_UNASSIGNED | A Private MEC which is not assigned to a Realm. |
| MEC_STATE_SHARED | A Shared MEC. |
A Shared MEC has a set of zero or more member Realms.
At platform boot, the state of MEC zero is MEC_STATE_SHARED.
At platform boot, the state of every MEC in the range
[1, MAX_MECID] is MEC_STATE_PRIVATE_UNASSIGNED.
The input values of RMI_REALM_CREATE include a MECID.
RMI_REALM_CREATE fails if any of the following is true:
- The MECID is not valid.
- The state of the MEC is MEC_STATE_PRIVATE_ASSIGNED.
On successful execution of RMI_REALM_CREATE:
- If the state of the MEC is MEC_STATE_PRIVATE_UNASSIGNED then the state becomes MEC_STATE_PRIVATE_ASSIGNED.
- If the state of the MEC is MEC_STATE_SHARED then the new Realm is added to the Shared MEC.
The RMI_MEC_SET_SHARED command changes the state of a MEC from MEC_STATE_PRIVATE_UNASSIGNED to MEC_STATE_SHARED.
Execution of RMI_MEC_SET_SHARED fails if any of the following is true:
- The MECID provided by the Host is not valid.
- The MECID provided by the Host identifies a MEC whose current state is not MEC_STATE_PRIVATE_UNASSIGNED.
- Any valid MECID identifies a Shared MEC. This means that there can be at most a single Shared MEC in existence at a time.
The RMI_MEC_SET_PRIVATE command changes the state of a MEC from MEC_STATE_SHARED to MEC_STATE_PRIVATE_UNASSIGNED.
Execution of RMI_MEC_SET_PRIVATE fails if any of the following is true:
- MAX_MECID is zero.
- The MECID provided by the Host is not valid.
- The MECID provided by the Host identifies a MEC whose current state is not MEC_STATE_SHARED.
- The MECID provided by the Host identifies a Shared MEC which contains a non-zero number of Realms.
On a platform which reports MAX_MECID to be zero, all Realms use the Shared MEC identified by MECID zero.
On a platform which reports MAX_MECID. Use the Shared MEC for some Realms; for the remaining Realms, assign a Private MEC to each, with the total number of this latter set of Realms not exceeding MAX_MECID. On a platform which reports MAX_MECID to be non-zero, the Host can choose between the following approaches:
- Use the Shared MEC for all Realms.
- Assign a Private MEC to each Realm, with the total number of Realms not exceeding MAX_MECID.
- Use the Shared MEC for some Realms; for the remaining Realms, assign a Private MEC to each, with the total number of this latter set of Realms not exceeding MAX_MECID.
The MEC policy of a Realm is reflected in the Realm attestation token.
On platform boot, the encryption context associated with every MEC changes.
When the state of a MEC changes, the encryption context associated with that MEC changes.
To illustrate the points at which encryption contexts must change, consider the following sequence:
| Step | Reason for encryption context change |
|---|---|
| Platform boot | Platform boot |
| RMI_REALM_CREATE(rd=a, mecid=0) | |
| RMI_REALM_CREATE(rd=b, mecid=0) | |
| RMI_REALM_DESTROY(rd_a) | |
| RMI_REALM_DESTROY(rd_b) | |
| RMI_MEC_SET_PRIVATE(mecid=0) | MEC_STATE_SHARED to MEC_STATE_PRIVATE_UNASSIGNED |
| RMI_REALM_CREATE(rd=c, mecid=0) | MEC_STATE_PRIVATE_UNASSIGNED to MEC_STATE_PRIVATE_ASSIGNED |
| RMI_REALM_DESTROY(rd_c) | MEC_STATE_PRIVATE_ASSIGNED to MEC_STATE_PRIVATE_UNASSIGNED |
| RMI_REALM_CREATE(rd=d, mecid=0) | MEC_STATE_PRIVATE_UNASSIGNED to MEC_STATE_PRIVATE_ASSIGNED |
See also:
12 Commands
This chapter describes how RMM commands are defined in this specification.
12.1 Overview
The RMM exposes the following interfaces to the Host:
- The Realm Management Interface (RMI)
Any other SMC executed by a Realm returns SMCCC_NOT_SUPPORTED.The RMM exposes the following interfaces to a Realm:
- The Realm Services Interface (RSI)
- The Power State Coordination Interface (PSCI)
The RMM exposes the following interfaces to a Realm:Any other SMC executed by a Realm returns SMCCC_NOT_SUPPORTED.
An RMM interface consists of a set of RMM commands.
An RMM interface is compliant with the SMC Calling Convention (SMCCC).
SMCCC version >= 1.2 is required.
SMCCC version 1.2 increases the number of SMC64 arguments and return values from 4 to 17. Some RMM commands use more than 4 input or output values.
On a CCA platform which implements FEAT_SVE, SMCCC version >= 1.3 is required.
SMCCC version 1.3 introduces a bit in the FID which a caller can use to indicate that SVE state does not need to be preserved across the SMC call.
On a CCA platform which implements FEAT_SME, SMCCC version >= 1.4 is required.
SMCCC version 1.4 adds support for preservation of SME state across an SMC call.
An RMM command uses the SMC64 calling convention.
To determine whether an RMM interface is implemented, software should use the following flow:
Determine whether the SMCCC_VERSION command is implemented, following the procedure described in Arm SMC Calling Convention [16].
Check that the SMCCC version is >= 1.1.
Execute the <Interface>.Version command, which returns:
- SMCCC_NOT_SUPPORTED (-1) if <Interface> is not implemented.
- A version number (>0) if <Interface> is implemented.
All data types defined in this specification are little-endian.
12.2 Command definition
The definition of an RMM command consists of:
- A function identifier (FID)
- A set of input values (referred to as “arguments” in SMCCC)
- A set of output values (referred to as “results” in SMCCC)
- A set of context values
- A partially-ordered set of failure conditions
- A set of success conditions
- A set of footprint items
Each failure condition, success condition and footprint item has an associated identifier. Identifiers are unique within each of the above groups, within each command.
An identifier has no meaning. It is only a label by which a given condition or footprint item can be referred to.
On calling an RMI or RSI command, any of X1 - X16 which are not specified as input values in the command definition SBZ.
On return from an RMI or RSI command, any of X0 - X16 which are not specified as output values in the command definition MBZ.
See also:
12.2.1 Example command
The following command, EXAMPLE_ADD, is an example of how the components of an RMM command definition are presented in this document.
This command takes as an input value the address
params_ptr of an NS Granule which contains two integer
values x and y. On successful execution of the
command:
- The output value
sumcontains the sum ofsum == params.x + params.andy - The output value
zeroindicates whether either ofxoryis zero == (params.x == 0) || (params.y == 0)
EXAMPLE_ADD is defined as follows:
Interface
FID
0x042
Success
conditions
Input values
| Name | Register | Field | Type | Description |
|---|---|---|---|---|
resultfid |
X0 |
[15:0][63:0] | CommandReturnCodeUInt64 | Command return statusFID |
sumparams_ptr |
X1 |
[63:0] | UInt64Address | Sum of x and yPA of parameters |
Context
The EXAMPLE_ADD command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
params |
ExampleParams | Params(params_ptr) |
false | Parameters |
Output values
| Name | Register | Field | Type | Description |
|---|---|---|---|---|
fidresult |
X0 |
[63:0][15:0] | UInt64CommandReturnCode | Command FIDreturn status |
params_ptrsum |
X1 |
[63:0] | AddressUInt64 | PA of parametersSum of x and y |
zero |
X2 |
[63:0] | UInt64 | Whether either x or y was zero |
Failure conditions
| ID | Condition |
|---|---|
0x042params_align
FID
Interface |
|
params_gpt |
|
Success conditions
EXAMPLE_ADD is defined as follows: The output value| ID | Post-condition |
|---|---|
sum contains the |
|
zero indicates whether either of
|
|
12.3 Command registers
An FID is a value which identifies a particular RMM command.
The FID of an RMM command is unique among the RMM commands in an RMM interface.
An FID is read from general-purpose register X0.
An input value is a value read by an RMM command from general-purpose registers.
An output value is a value written by an RMM command to general-purpose registers.
A command return code is a value which specifies whether an RMM command succeeded or failed.
A command return code is written to general-purpose register X0.
12.4 Command condition expressions
A condition expression is an expression which evaluates to a boolean value.
Following expansion of macros, a condition expression is a valid expression in Arm Specification Language (ASL).
See also:
12.5 Command context values
A context value is a value which is derived from the value of a command input register and which is used by a command condition expression.
A context value can be thought of as a local variable for use by command condition expressions.rtt_base)
By introducing a context value params with the value RealmParams(params_ptr)For example, thisconsider the following example command condition expression can be re-written as: expression:
!AddrIsGranuleAligned(RealmParams(params_ptr).rtt_base)For exampleBy introducing a context value params with the value
RealmParams(params_ptr), consider the following examplethis command condition
expression: expression
can be re-written as:
!AddrIsGranuleAligned(params.rtt_base)The before property of a context value indicates whether
its expression is re-evaluated after the command has executed.
before = true: the expression is not re-evaluated after the command has executedbefore = false: the expression is re-evaluated after the command has executed
Specifying before = true for a context value allows
system state to be sampled before command execution, and then used after
command execution in a command success condition.
For example, the RMI_REALM_DESTROY command takes as an input value
the address rd of a Realm Descriptor. Successful execution
of the command results observable effects including the following:
- The state of the RD Granule(rtt_base) changes from RD to DELEGATED
- The state of the RTT base Granule, whose address was previously held in the RD, changes from RTT to DELEGATED
The address of the RTT base Granule is not included in the input values of the command.state == DELEGATED
The state change of the RTT Granule can then be expressed as:A context value is defined as follows:
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
rtt_base |
Address | Realm(rd).rtt_base |
true | RTT base address |
A context value is defined as follows:The state change of the RTT Granule can then be expressed as:
The address of the RTT baseGranule is not included in the input
values of the command(rtt_base).
The state of the RD Granule changes from RD to== DELEGATED
The state of the RTT base Granule, whose address was previously held
in the RD, changes from RTT to DELEGATED
For example, the RMI_REALM_DESTROY command takes as an input value
the address rd of a Realm Descriptor. Successful execution
of the command results observable effects including the following:
Specifying before = true for a context value allows
system state to be sampled before command execution, and then used after
command execution in a command success condition.The before property of a context value has no effect if the value is only used in command failure conditions.
An in-memory value is a value passed to a command via an in-memory data structure, the address of which is passed in an input register.
An in-memory value is a context value.
See also:
- Section 15.3.25
12.6 Command failure conditions
An RMM command failure condition defines a way in which the command can fail.
A failure condition consists of a pre-condition and a post-condition.
A failure pre-condition can be thought of as the “trigger” of the failure: if the pre-condition is true then the command fails.
A failure post-condition can be thought of as the “effect” of the failure: if the command failed due to a particular trigger, then the post-condition defines the error code which is returned.
A failure pre-condition is a condition expression whose terms can include input values and context values.
A failure post-condition is a condition expression whose terms can include input values and context values.
The specification does not state whether an individual ordering relation is a well-formedness ordering or a behavioral orderingObservability of the checking of command failure conditions is subject to a partial order.
The same information is also presented graphically, with failure conditions represented as nodes andAn ordering relations represented as edges. Orderings are specified between groups of failure conditions. For example, the expression [A, B] < [C, D] means that both conditions A and B precede both conditions C and D. The absence of an ordering relation “A precedes B” means that, if the pre-conditions of A and B are both true then either the post-condition of A is observed or the post-condition of B is observed.of the following:
The pre-condition of B is well-formed only if the pre-condition of A is false. This is referred to as a well-formedness ordering.
If the pre-conditions of A and B are both true, then the post-condition of A is observed. This is referred to as a behavioral ordering.
AnThe absence of an ordering relation “A precedes B” means that, if the pre-conditions of A and B are both true then either of the following: Observability of the checking of command failure conditions is subject to a partial orderthe post-condition of A is observed or the post-condition of B is observed.
Orderings are specified between groups of failure conditions. For
example, the expression [A, B] < [C, D] means that both
conditions A and B precede both conditions C and D.
The same information is also presented graphically, with failure conditions represented as nodes and ordering relations represented as edges.
The specification does not state whether an individual ordering relation is a well-formedness ordering or a behavioral ordering.
A given implementation of the RMM is expected to have deterministic behavior. That is, for a runtime instance of the RMM in a particular state, two executions of a command without an interleaving of other commands, with the same input values, results in the same outcome (either success, or the same failure condition.)
If a failure pre-condition evaluates to true then the corresponding failure post-condition evaluates to true.
If a failure pre-condition evaluates to true then the command is aborted.
If a command fails then all output values except for X0 are undefined, unless stated otherwise.
If no failure pre-condition evaluates to true then the command succeeds.
12.7 Command success conditions
An RMM command success condition defines an observable effect of a successful execution of the command.
A success condition is a condition expression whose terms can include input values, context values and output values.
The order in which success conditions are listed has no architectural significance.
If an RMM command succeeds then the return code is <Interface>_SUCCESS.
If an RMM command succeeds then all of its success conditions evaluate to true.
12.8 Concrete and abstract types
A concrete type is a type which has a defined encoding.
Examples of concrete types include:
- An integer which has a defined bit width.
- An enumeration within which each label is associated with a unique binary value.
- A struct which has a defined width, and within which each member has a defined position. The type of each member of a concrete struct is a concrete type.
Examples of concreteConcrete types include:are used to define command input values and output values.
AAn concreteabstract type is a type which hasdoes not have a defined encoding.
Examples of concrete types include:
- An integer which does not have a defined bit width.
- An enumeration which has a set of labels, but which does not define a binary value for each label.
- A struct which has a set of members, but which does not define a struct width nor a position for each member. The type of each member of an abstract struct is an abstract type.
ConcreteAbstract types are used to define command input values and output valuesmodel the internal state of the RMM.
A command failure condition or success condition may need to test for
logical equality between a concrete type and a corresponding abstract
type. For example, the command may set the value of an internal RMM
variable to match the value of a command input. To enable such
comparisons, the specification defines an Equal() function
for each pair of corresponding concrete and abstract types.
See also:
- Section 14.2526
12.9 Command footprint
The footprint of an RMM command defines the set of state items which successful execution of the command can modify.
The footprint of an RMM command may include state items which are not modified by successful execution of the command.
If an RMM command changes the state of a Granule then the footprint typically does not include all attributes of the object which is created or destroyed.
For example, the footprint of RMI_REALM_CREATE includes the state of the RD Granule, but does not include attributes of the newly-created Realm.
If an RMM command changes the state of a Granule then the footprint typically does not include all attributes of the object which is created or destroyed.Except for items in the footprint of an RMM command and registers in the output values of the RMM command, execution of the command does not have any observable effects.
12.10 Command testing
Command definitions can be used to generate testbenches which check whether an implementation complies with the specified failure and success conditions.
Note that the syntax x IMPLIES y, which is logically equivalent to !x || y, is not yet defined in ASL.A testbench for the EXAMPLE_ADD command presented above would look similar to the following:
// Test EXAMPLE_ADD command
Test_ExampleAdd(Registers regs_in)
// Unpack input values
RmmPa params_ptr = regs_in.X1;
// Evaluate context values
ExampleParams params = ExampleParams(params_ptr);
// Evaluate failure pre-conditions
boolean params_align_pre = !AddrIsGranuleAligned(params_ptr);
boolean params_gpt_pre = Granule(params_ptr).gpt != GPT_NS;
// Execute command
regs_out = RmiExampleAdd(regs_in);
// Pack output values
CommandReturnCode result = regs_out.X0;
integer sum = regs_out.X1;
integer zero = regs_out.X2;
// Check return code
boolean success = (result == Success);
// Evaluate failure post-conditions
boolean params_align_post = result == Status(ErrorInput, 1);
boolean params_gpt_post = result == Status(ErrorInputMemory, 0);
// Evaluate success conditions
boolean sum_post = sum == params.x + params.y;
boolean zero_post = zero == (params.x == 0) || (params.z == 0);
// Check failure conditions, in order specified
assert params_align_pre IMPLIES params_align_post;
assert (!params_align_pre && params_gpt_pre) IMPLIES params_gpt_post;
// Check that, if no failure pre-condition was violated, command succeeded
assert (!params_align_pre && !params_gpt_pre) IMPLIES success;
// Check success conditions, without any ordering
assert success IMPLIES S01_post;
assert success IMPLIES S02_post;A testbench for the EXAMPLE_ADD command presented above would look
similar to the following:Note that the syntax x IMPLIES y, which is logically
equivalent to !x || y, is not yet defined in ASL.
13 Interface versioning
This section describes how the RMI and RSI interfaces are versioned, and how the caller of each can determine whether there exists a mutually acceptable revision of the interface via which it can communicate with the RMM.
Other interfaces exposed by the RMM, such as PSCI, may define their own versioning schemes which differ from that used by RMI and RSI. For details, refer to the specification of the interface concerned.
If majP != majQ then the two interfaces may contain incompatible commandsRevisions of the RMI and the RSI are identified by a (major, minor) version tuple.
If majP == majQ and
minP < minQ then:
Every command defined in P has the same behavior in Q, when
called with input values that are specified as valid in P.
A command defined in P may accept additional input values in Q.
These could be provided via any of:
Input registers which were unused in P.
Input memory locations which were specified as SBZ in P.
Encodings which were specified as reserved in P.
A command defined in P may return additional output values in Q.
These could be returned via any of:
Output registers which were unused in P.
Output memory locations which were specified as MBZ in P.
Encodings which were specified as reserved in P.
Q may contain additional commands which are not present in
P.
P is less than Q if one of the following conditions is
true:
majP < majQ
majP == majQ and minP
< minQ
The semantics of this version tuple are as follows. For two revisions
of the interface P = (majP, minP)
and
Q = (majQ, minQ):
Revisions of the RMI and the RSI are identified by a (major, minor) version tupleIf majP != majQ then the two interfaces may contain incompatible commands.
If majP == majQ and minP < minQ then:
Every command defined in P has the same behavior in Q, when called with input values that are specified as valid in P.
A command defined in P may accept additional input values in Q. These could be provided via any of:
- Input registers which were unused in P.
- Input memory locations which were specified as SBZ in P.
- Encodings which were specified as reserved in P.
A command defined in P may return additional output values in Q. These could be returned via any of:
- Output registers which were unused in P.
- Output memory locations which were specified as MBZ in P.
- Encodings which were specified as reserved in P.
Q may contain additional commands which are not present in P.
P is less than Q if one of the following conditions is true:
- majP < majQ
- majP == majQ and minP < minQ
For each interface, an RMM implementation supports a set of revisions. The size of this set is at least one.
If an RMM implementation supports a given interface revision (x, y) then Arm expects that it will also supports all earlier revisons with the same major version number. That is:
(x, 0), (x, 1) … (x, y-1), (x, y).
A possible exception to this may occur if a security vulnerability is discovered in a particular revision of the interface. For example, if interface revision (x, bad) is found to contain a vulnerability then an RMM implementation may choose to support the following set of revisions:
(x, 0), (x, 1) … (x, bad-1), (x, bad+1) … (x, y-1), (x, y).
A possible exception to thisThe set of interface revisions supported by an RMM implementation may occur if a security vulnerability is discovered in a particular revision of the interface. For example include revisons with different major version numbers, if interface revision (x, bad) is found to contain a vulnerability then an RMM implementation may choose to support the following set of revisions:for example:
If an RMM implementation supports a given interface revision (x, y) then Arm expects that it will also supports all earlier revisons with the same major version number. That is: I GLDQG(x1, 0), (x1, 1) … (x1, y-1m), (x, y).
(1, 0), (1, 1) … (1, m) The set of interface revisions supported by an RMM implementation may include revisons with different major version numbers, for example:(2, 0), (2, 1) … (2, n)
The RMI_VERSION and RSI_VERSION commands allow the caller and the RMM to determine whether there exists a mutually acceptable revision of the interface via which the two components can communicate.
In each case:
- The caller provides a requested interface revision.
- The output values include a status code and two revisions which are supported by the RMM: a lower revision and a higher revision.
- The higher revision value is the highest interface revision which is supported by the RMM.
- The lower revision is less than or equal to the higher revision.
The status code and lower revision output values indicate which of the following is true, in order of precedence:
The RMM supports an interface revision which is compatible with the requested revision.
- The status code is “success”.
- The lower revision is equal to the requested revision.
The RMM does not support an interface revision which is compatible with the requested revision The RMM supports an interface revision which is incompatible with and less than the requested revision.
- The status code is “failure”.
- The lower revision is the highest interface revision which is both less than the requested revision and supported by the RMM.
The RMM does not support an interface revision which is compatible with the requested revision The RMM supports an interface revision which is incompatible with and greater than the requested revision.
- The status code is “failure”.
- The lower revision is equal to the higher revision.
The following table shows how each of a set of example scenarios maps onto the above outcomes.
| Scenario | Revisions supported by RMM | Revision requested by caller | Outcome | “Lower revision” output value | “Higher revision” output value |
|---|---|---|---|---|---|
| 1 | (1, 0) | (1, 0) | Success (a) | (1, 0) | (1, 0) |
| 2 | (1, 0), (1, 1) | (1, 0) | Success (a) | (1, 0) | (1, 1) |
| 3 | (1, 0), (2, 0) | (1, 0) | Success (a) | (1, 0) | (2, 0) |
| 4 | (1, 0) | (1, 1) | Failure (b) | (1, 0) | (1, 0) |
| 5 | (1, 0), (1, 1) | (1, 2) | Failure (b) | (1, 1) | (1, 1) |
| 6 | (1, 0), (1, 1) | (2, 0) | Failure (b) | (1, 1) | (1, 1) |
| 7 | (1, 0), (1, 1), (1, 3) | (1, 2) | Failure (b) | (1, 1) | (1, 3) |
| 8 | (1, 0) | (2, 0) | Failure (b) | (1, 0) | (1, 0) |
| 9 | (1, 0) | (2, 1) | Failure (b) | (1, 0) | (1, 0) |
| 10 | (1, 0), (1, 1) | (2, 0) | Failure (b) | (1, 1) | (1, 1) |
| 11 | (1, 0), (1, 1) | (2, 1) | Failure (b) | (1, 1) | (1, 1) |
| 12 | (1, 0), (1, 1), (2, 0) | (2, 1) | Failure (b) | (2, 0) | (2, 0) |
| 13 | (2, 0) | (1, 0) | Failure (c) | (2, 0) | (2, 0) |
| 14 | (2, 0) | (1, 1) | Failure (c) | (2, 0) | (2, 0) |
| 15 | (2, 0), (2, 1) | (1, 0) | Failure (c) | (2, 1) | (2, 1) |
14 Command condition functions
This chapter describes functions which are used in command condition expressions.
See also:
- Section 12.4
14.1 AddrInRange function
Returns TRUE if addr is within
[base, base+size].
func AddrInRange(
addr : Address,
base : Address,
size : integer) => boolean
begin
return ((UInt(addr) >= UInt(base))
&& (UInt(addr) <= UInt(base) + size));
end
14.2 AddrIsAligned function
Returns TRUE if address addr is aligned to an
n byte boundary.
func AddrIsAligned(
addr : Address,
n : integer) => boolean
14.3 AddrIsAuxLive function
Returns TRUE if IPA addr is auxiliary-live,
that is live in any auxiliary RTT.
func AddrIsAuxLive(
addr : Address,
realm : RmmRealm) => boolean
14.4 AddrIsGranuleAligned function
Returns TRUE if address addr is aligned to the size of a
Granule.
func AddrIsGranuleAligned(
addr : Address) => boolean
func AddrIsGranuleAligned(
addr : integer) => boolean
See also:
- Section 2.2
14.5 AddrIsNotRttLevelAlignedAny AddrIsProtected function
For each of a set of RTT walk results,Returns TRUE if Addressaddress addr
is not aligned to the size of the address range described by the RTT in
the level reached by the walk, return the index of that walk among the
set is a Protected IPA for
realm.
func AddrIsProtected( addr is aligned for all RTT walk results, return -1. func AddrIsNotRttLevelAlignedAny( addr : Address, walksrealm : RmmRttWalkResultsRmmRealm) => integerboolean begin for index = 0 to 3 do var walk = walks[index]; if !AddrIsRttLevelAlignedreturn UInt(addr, walk) < 2^(realm.levelipa_width - 1) then return index; end end return -1; end
14.6 AddrIsProtected AddrIsRttLevelAligned function
Returns TRUE if addressAddress addr is a Protected IPA for
aligned to the size of
the address range described by an RTTE in a level realmlevel
RTT.
Returns FALSE if level is invalid.
func AddrIsProtectedAddrIsRttLevelAligned( addr : Address, realmlevel : RmmRealminteger) => boolean begin return UInt(addr) < 2^(realm.ipa_width - 1); end
14.7 AddrIsRttLevelAligned AddrIsWithin function
Returns TRUE if Addressaddress addr is aligned to the size of
the addresswithin the outer range described by an RTTE in a level
level[base, top)
RTT.
func AddrIsRttLevelAlignedAddrIsWithin( addr : Address, levelbase : integerAddress, top : Address) => boolean begin var addr_int : integer = UInt(addr); var top_int : integer = UInt(top); var base_int : integer = UInt(base); return ((UInt(addr) >= UInt(base)) && (UInt(addr) < UInt(top))); end
14.8 AddrRangeIsAuxLive function
Returns TRUE if any IPA in range [base, top) is
auxiliary-live, that is live in any auxiliary RTT.
func AddrRangeIsAuxLive(
base : Address,
top : Address,
realm : RmmRealm) => boolean
14.9 AddrRangeIsProtected function
Returns TRUE if all addresses in range [base, top) are
Protected IPAs for realm.
func AddrRangeIsProtected(
base : Address,
top : Address,
realm : RmmRealm) => boolean
begin
var size = UInt(top) - UInt(base);
return (AddrIsProtected(base, realm)
&& size > 0
&& size < 2^realm.ipa_width
&& AddrIsProtected(ToAddress(UInt(top) - 1), realm));
end
14.10 AlignDownToRttLevelAddrRangeIsWithin function
Round down Returns TRUE if all addresses in the inner range
addr[inner_base, inner_top) to align to the size of the address
are within the outer range described by an RTTE in a level
level[outer_range, outer_top) RTT.
func AlignDownToRttLevelAddrRangeIsWithin( addrinner_base : Address, levelinner_top : integerAddress, outer_base : Address, outer_top : Address) => Addressboolean begin return (AddrIsWithin 14.11 AlignUpToRttLevel function Round up addr to align to the size of the address range described by an RTTE in a level level RTT. func AlignUpToRttLevel( addr : Addressinner_base, level : integer outer_base, outer_top) => Address 14.12 AuxAlias16 function Returns TRUE if any of the first count entries in a list of auxiliary Granule addresses are aliased - either among themselves, or with the address of another RMM object. func AuxAlias16( obj : Address, aux : array [16] of Address, count : integer) => boolean begin assert 0 <= count && AddrIsWithin(inner_top, outer_base, outer_top)); end
14.11 AlignDownToRttLevel function
Round down addr to align to the size of the address
range described by an RTTE in a level level RTT.
func AlignDownToRttLevel( addr : Address, level : integer) => Address
14.12 AlignUpToRttLevel function
Round up addr to align to the size of the address range
described by an RTTE in a level level RTT.
func AlignUpToRttLevel( addr : Address, level : integer) => Address
14.13 AuxAlias16 function
Returns TRUE if any of the first count entries in a list
of auxiliary Granule addresses are aliased - either among themselves, or
with the address of another RMM object.
func AuxAlias16( obj : Address, aux : array [16] of Address, count : integer) => boolean begin assert 0 <= count && count <= 16; var sorted = AuxSort(aux, count); for i = 0 to count - 1 do if sorted[i] == obj then return TRUE; end if i >= 1 && sorted[i] == sorted[i - 1] then return TRUE; end end return FALSE; end
14.1314 AuxAlias32 function
Returns TRUE if any of the first count entries in a list
of auxiliary Granule addresses are aliased - either among themselves, or
with the address of another RMM object.
func AuxAlias32(
obj : Address,
aux : array [32] of Address,
count : integer) => boolean
begin
assert 0 <= count && count <= 32;
var sorted = AuxSort(aux, count);
for i = 0 to count - 1 do
if sorted[i] == obj then
return TRUE;
end
if i >= 1 && sorted[i] == sorted[i - 1] then
return TRUE;
end
end
return FALSE;
end
14.1415 AuxAligned16 function
Returns TRUE if the first count entries in a list of
auxiliary Granule addresses are aligned to the size of a Granule.
func AuxAligned16(
aux : array [16] of Address,
count : integer) => boolean
begin
assert 0 <= count && count <= 16;
for i = 0 to count - 1 do
if !AddrIsGranuleAligned(aux[i]) then
return FALSE;
end
end
return TRUE;
end
14.1516 AuxAligned32 function
Returns TRUE if the first count entries in a list of
auxiliary Granule addresses are aligned to the size of a Granule.
func AuxAligned32(
aux : array [32] of Address,
count : integer) => boolean
begin
assert 0 <= count && count <= 32;
for i = 0 to count - 1 do
if !AddrIsGranuleAligned(aux[i]) then
return FALSE;
end
end
return TRUE;
end
14.1617 AuxEqual16 function
Returns TRUE if the first count entries in two lists of
auxiliary Granule addresses are equal.
func AuxEqual16(
aux1 : array [16] of Address,
aux2 : array [16] of Address,
count : integer) => boolean
begin
assert 0 <= count && count <= 16;
for i = 0 to count - 1 do
if aux1[i] != aux2[i] then
return FALSE;
end
end
return TRUE;
end
14.1718 AuxEqual32 function
Returns TRUE if the first count entries in two lists of
auxiliary Granule addresses are equal.
func AuxEqual32(
aux1 : array [32] of Address,
aux2 : array [32] of Address,
count : integer) => boolean
begin
assert 0 <= count && count <= 32;
for i = 0 to count - 1 do
if aux1[i] != aux2[i] then
return FALSE;
end
end
return TRUE;
end
14.19 AuxStateEqual16AuxSort function
Returns TRUE if the state of theSort first count entries in array of auxiliary Granule
addresses.
func AuxSort( addrs : array [16] of Address, count : integer) => array [16] of Address
func AuxSort( addrs : array [32] of Address, count : integer) => array [32] of Address
14.20 AuxStateEqual16 function
Returns TRUE if the state of the first count entries in
a list of auxiliary Granule addresses is equal to
state.
func AuxStateEqual16(
aux : array [16] of Address,
count : integer,
state : RmmGranuleState) => boolean
begin
assert 0 <= count && count <= 16;
for i = 0 to count - 1 do
if (!PaIsDelegable(aux[i])
|| GranuleAt(aux[i]).state != state) then
return FALSE;
end
end
return TRUE;
end
14.2021 AuxStateEqual32 function
Returns TRUE if the state of the first count entries in
a list of auxiliary Granule addresses is equal to
state.
func AuxStateEqual32(
aux : array [32] of Address,
count : integer,
state : RmmGranuleState) => boolean
begin
assert 0 <= count && count <= 32;
for i = 0 to count - 1 do
if (!PaIsDelegable(aux[i])
|| GranuleAt(aux[i]).state != state) then
return FALSE;
end
end
return TRUE;
end
14.22 CurrentRealmAuxStates function
Returns the current RealmInductive function which identifies the states of the first
count entries in a list of auxiliary Granules.
This function is used in the definition of command footprint.
func CurrentRealmAuxStates( aux : array [16] of Address, count : integer) => RmmRealm
func AuxStates( aux : array [32] of Address, count : integer)
14.23 CurrentRecCurrentRealm function
Returns the current RECRealm.
func CurrentRecCurrentRealm() => RmmRecRmmRealm
14.24 DeviceCommunicate CurrentRec function
Process device communication data and return the new state of the device transactionReturns the current REC.
func DeviceCommunicateCurrentRec( pdev : RmmPdev, data : RmiDevCommData) => RmmDevCommStateRmmRecfunc DeviceCommunicate( vdev : RmmVdev, data : RmiDevCommData) => RmmDevCommState func DeviceCommunicate( vdev : RmmRdev) => RmmDevCommState
14.25 Equal DeviceCommunicate function
Process device communication data and return the new state of the device transaction.
func DeviceCommunicate( pdev : RmmPdev, data : RmiDevCommData) => RmmDevCommState
func DeviceCommunicate( vdev : RmmVdev, data : RmiDevCommData) => RmmDevCommState
func DeviceCommunicate( vdev : RmmRdev) => RmmDevCommState
14.26 Equal function
Check whether concrete and abstract values are equal
func Equal(
abstract : RmmFeature,
concrete : RmiFeature) => boolean
func Equal(
concrete : RmiFeature,
abstract : RmmFeature) => boolean
func Equal(
abstract : RmmHashAlgorithm,
concrete : RmiHashAlgorithm) => boolean
func Equal(
concrete : RmiHashAlgorithm,
abstract : RmmHashAlgorithm) => boolean
func Equal(
abstract : RmmLfaPolicy,
concrete : RmiLfaPolicy) => boolean
func Equal(
concrete : RmiLfaPolicy,
abstract : RmmLfaPolicy) => boolean
func Equal(
abstract : RmmPdevIdeRmmPdevProtConfig,
concrete : RmiPdevIdeRmiPdevProtConfig) => boolean
func Equal(
concrete : RmiPdevIdeRmiPdevProtConfig,
abstract : RmmPdevIdeRmmPdevProtConfig) => boolean
func Equal(
abstract : RmmPdevProtConfigRmmPdevState,
concrete : RmiPdevProtConfigRmiPdevState) => boolean
func Equal(
concrete : RmiPdevProtConfigRmiPdevState,
abstract : RmmPdevProtConfigRmmPdevState) => boolean
func Equal(
abstract : RmmPdevSpdmRmmPlaneRttFeature,
concrete : RmiPdevSpdmRmiPlaneRttFeature) => boolean
func Equal(
concrete : RmiPdevSpdmRmiPlaneRttFeature,
abstract : RmmPdevSpdmRmmPlaneRttFeature) => boolean
func Equal(
abstract : RmmPdevStateRmmRecRunnable,
concrete : RmiPdevStateRmiRecRunnable) => boolean
func Equal(
concrete : RmiPdevStateRmiRecRunnable,
abstract : RmmPdevStateRmmRecRunnable) => boolean
func Equal(
abstract : RmmPlaneRttFeatureRmmRipas,
concrete : RmiPlaneRttFeatureRmiRipas) => boolean
func Equal(
concrete : RmiPlaneRttFeatureRmiRipas,
abstract : RmmPlaneRttFeatureRmmRipas) => boolean
func Equal(
abstract : RmmRecRunnableRmmVdevState,
concrete : RmiRecRunnableRmiVdevState) => boolean
func Equal(
concrete : RmiRecRunnableRmiVdevState,
abstract : RmmRecRunnableRmmVdevState) => boolean
func Equal(
abstract : RmmRdevState,
concrete : RsiDeviceState) => boolean
func Equal( concrete : RsiDeviceState, abstract : RmmRdevState) => boolean
func Equal( abstract : RmmFeature, concrete : RsiFeature) => boolean
func Equal( concrete : RsiFeature, abstract : RmmFeature) => boolean
func Equal( abstract : RmmHashAlgorithm, concrete : RsiHashAlgorithm) => boolean
func Equal( concrete : RsiHashAlgorithm, abstract : RmmHashAlgorithm) => boolean
func Equal( abstract : RmmRipas, concrete : RmiRipasRsiRipas) => boolean
func Equal(
concrete : RmiRipasRsiRipas,
abstract : RmmRipas) => boolean
func Equal(
abstract : RmmVdevStateRmmRipasChangeDestroyed,
concrete : RmiVdevStateRsiRipasChangeDestroyed) => boolean
func Equal(
concrete : RmiVdevStateRsiRipasChangeDestroyed,
abstract : RmmVdevStateRmmRipasChangeDestroyed) => boolean
func Equal(
abstract : RmmRdevState,
concrete : RsiDeviceState) => boolean
func Equal(
concrete : RsiDeviceState,
abstract : RmmRdevState) => boolean
func Equal(
abstract : RmmFeature,
concrete : RsiFeature) => boolean
func Equal(
concrete : RsiFeature,
abstract : RmmFeature) => boolean
func Equal(
abstract : RmmHashAlgorithm,
concrete : RsiHashAlgorithm) => boolean
func Equal(
concrete : RsiHashAlgorithm,
abstract : RmmHashAlgorithm) => boolean
func Equal(
abstract : RmmRipas,
concrete : RsiRipas) => boolean
func Equal(
concrete : RsiRipas,
abstract : RmmRipas) => boolean
func Equal(
abstract : RmmRipasChangeDestroyed,
concrete : RsiRipasChangeDestroyed) => boolean
func Equal(
concrete : RsiRipasChangeDestroyed,
abstract : RmmRipasChangeDestroyed) => boolean
See also:
- Section 12.8
14.27 FeatureToRsiFeatureToRmi function
Convert feature bit to RSIRMI type.
func FeatureToRsiFeatureToRmi( value : RmmFeature) => RsiFeatureRmiFeature begin case value of when FEATURE_FALSE => return RSI_FEATURE_FALSERMI_FEATURE_FALSE; when FEATURE_TRUE => return RSI_FEATURE_TRUERMI_FEATURE_TRUE; end end
14.28 Gicv3ConfigIsValid FeatureToRsi function
Convert feature bit to RSI type.
func FeatureToRsi( value : RmmFeature) => RsiFeature begin case value of when FEATURE_FALSE => return RSI_FEATURE_FALSE; when FEATURE_TRUE => return RSI_FEATURE_TRUE; end end
14.29 Gicv3ConfigIsValid function
Returns TRUE if the values of all gicv3_* attributes are
valid.
func Gicv3ConfigIsValid(
gicv3_hcr : bits(64),
gicv3_lrs : array [16] of bits(64)) => boolean
14.2930 GranuleAccessPermitted function
Returns TRUE if the Granule located at physical address
addr is accessible via pas.
func GranuleAccessPermitted(
addr : Address,
pas : RmmPhysicalAddressSpace) => boolean
begin
case GranuleAt(addr).gpt of
when GPT_NS => return (pas == PAS_NS);
when GPT_REALM => return (pas == PAS_REALM);
when GPT_SECURE => return (pas == PAS_SECURE);
when GPT_ROOT => return (pas == PAS_ROOT);
when GPT_AAP => return TRUE;
end
end
14.3031 GranuleAt function
Returns the Granule located at physical address
addr.
func GranuleAt(
addr : Address) => RmmGranule
See also:
- Section 2.2
14.3132 ImplFeatures function
Returns features supported by the implementation.
func ImplFeatures() => RmmFeatures
See also:
- Section 3
14.3233 MecMembers function
Returns number of Realms which are members of a given MEC.
func MecMembers(
mecid : bits(64)) => integer
See also:
- Section 11
14.3334 MecPolicy function
Returns policy associated with a given MEC.
func MecPolicy(
mecid : bits(64)) => RmmMecPolicy
begin
case MecState(mecid) of
when MEC_STATE_SHARED => return MEC_POLICY_SHARED;
when MEC_STATE_PRIVATE_ASSIGNED => return MEC_POLICY_PRIVATE;
when MEC_STATE_PRIVATE_UNASSIGNED => return MEC_POLICY_PRIVATE;
end
end
See also:
- Section 11
14.3435 MecState function
Returns state of a given MEC.
func MecState(
mecid : bits(64)) => RmmMecState
See also:
- Section 11
14.3536 MemPermLabelSupported function
Returns TRUE if the specified value is a valid encoding for a memory permission label and the label is supported by the implementation.
func MemPermLabelSupported(
label : bits(64)) => boolean
14.3637 MinAddress function
Returns the smaller of two addresses.
func MinAddress(
addr1 : Address,
addr2 : Address) => Address
begin
return ToAddress(Min(UInt(addr1), UInt(addr2)));
end
14.3738 MpidrEqual function
Returns TRUE if the specified MPIDR values are logically equivalent.
func MpidrEqual(
rmm_mpidr : bits(64),
rmi_mpidr : RmiRecMpidr) => boolean
begin
return (rmm_mpidr[ 3: 0] == rmi_mpidr.aff0
&& rmm_mpidr[15: 8] == rmi_mpidr.aff1
&& rmm_mpidr[23:16] == rmi_mpidr.aff2
&& rmm_mpidr[31:24] == rmi_mpidr.aff3);
end
14.3839 MpidrIsUsed function
Returns TRUE if the specified MPIDR value identifies a REC in the current Realm.
func MpidrIsUsed(
mpidr : bits(64)) => boolean
14.40 PdevAtPaIsDelegable function
Returns TRUE if the Granule located at physical address
addr is delegable.
func PaIsDelegable( addr : Address) => boolean
14.41 PdevAt function
Returns the PDEV object located at physical address
addr.
func PdevAt(
addr : Address) => RmmPdev
14.42 PdevFlagsPdevAuxCount function
Get RmiPdevFlags Returns the number of auxiliary Granules required for a PDEV with the specified flags.
The return value is guaranteed not to be greater than 32.
For a given flags value, this function always returns the same value.
func PdevFlagsPdevAuxCount( pdevflags : RmmPdevRmiPdevFlags) => RmiPdevFlags begin var flags : RmiPdevFlags; case pdev.spdm of when SPDM_TRUE => flags.spdm = RMI_SPDM_TRUE; when SPDM_FALSE => flags.spdm = RMI_SPDM_FALSE; end case pdev.ide of when IDE_FALSE => flags.ide = RMI_IDE_FALSE; when IDE_TRUE => flags.ide = RMI_IDE_TRUE; end return flags; endinteger
14.43 PlaneRegIsValidPdevFlags function
Get RmiPdevFlags value.
func PdevFlags( pdev : RmmPdev) => RmiPdevFlags begin var flags : RmiPdevFlags; case pdev.prot_config of when PDEV_IOCOH_E2E_IDE => flags.prot_config = RMI_PDEV_IOCOH_E2E_IDE; when PDEV_IOCOH_E2E_SYS => flags.prot_config = RMI_PDEV_IOCOH_E2E_SYS; when PDEV_FCOH_E2E_IDE => flags.prot_config = RMI_PDEV_FCOH_E2E_IDE; when PDEV_FCOH_E2E_SYS => flags.prot_config = RMI_PDEV_FCOH_E2E_SYS; end return flags; end
14.44 PlaneRegIsValid function
Whether encoding identifies a Plane register.
func PlaneRegIsValid(
realm : RmmRealm,
encoding : bits(64)) => boolean
14.4445 PlaneRegValue function
Value of a Plane register.
func PlaneRegValue(
realm : RmmRealm,
plane_idx : integer,
encoding : bits(64)) => bits(64)
14.46 PsciReturnCodePermittedPsciReturnCodeEncode function
Return encoding for a PsciReturnCode value.
func PsciReturnCodeEncode( value : PsciReturnCode) => bits(64)
14.47 PsciReturnCodePermitted function
Whether a PSCI return code is permitted.
func PsciReturnCodePermitted(
calling_rec : RmmRec,
target_rec : RmmRec,
value : PsciReturnCode) => boolean
begin
if value == PSCI_SUCCESS then
return TRUE;
end
var fid : bits(64) = calling_rec.gprs[0];
// Host is permitted to deny a PSCI_CPU_ON request, if the target
// CPU is not already on.
if (fid == FID_PSCI_CPU_ON
&& target_rec.flags.runnable != RUNNABLE
&& value == PSCI_DENIED) then
return TRUE;
end
return FALSE;
end
14.4748 RdevFromId function
Returns any RDEV identified by dev_id and assigned to
realm.
func RdevFromId(
realm : RmmRealm,
vdev_id : bits(64)) => RmmRdev
14.4849 RdevFromIds function
Returns the RDEV identified by the tuple (dev_id,
inst_id) and assigned to realm.
func RdevFromIds(
realm : RmmRealm,
vdev_id : bits(64),
inst_id : integer) => RmmRdev
14.4950 RdevIdIsValid function
Returns TRUE if vdev_id identifies a Realm device which
is assigned to realm.
func RdevIdIsValid(
realm : RmmRealm,
vdev_id : bits(64)) => boolean
14.5051 RdevIdsAreValid function
Returns TRUE if the tuple (vdev_id,
inst_id) identifies a Realm device which is assigned to
realm.
func RdevIdsAreValid(
realm : RmmRealm,
vdev_id : bits(64),
inst_id : integer) => boolean
14.5152 RdevMeasurementParamsValid function
Returns TRUE if the specified device measurement parameters are valid.
func RdevMeasurementParamsValid(
params : RsiDeviceMeasurementsParams) => boolean
begin
var no_ids : boolean = TRUE;
for i = 0 to 255 do
if (params.meas_ids[i] == RSI_TRUE) then
no_ids = FALSE;
end
end
if (no_ids) then
return FALSE;
end
for i = 0 to 7 do
if (params.meas_ids[i] == RSI_FALSE
&& params.meas_params[i] == RSI_TRUE) then
return FALSE;
end
end
return TRUE;
end
14.5253 ReadMemory function
Read contents of memory at address range [addr + offset, addr + offset + size)
offset and size are both numbers of bytes.
func ReadMemory(
addr : bits(64),
offset : integer,
size : integer) => bits(size * 8)
14.5354 RealmAt function
Returns the Realm whose RD is located at physical address
addr.
func RealmAt(
addr : Address) => RmmRealm
See also:
- Section 2.1
14.5455 RealmIsLive function
Returns TRUE if the Realm whose RD is located at physical address
addr is live.
func RealmIsLive(
addr : Address) => boolean
See also:
- Section 2.1.4
14.5556 RealmParamsSupported function
Returns TRUE if the Realm parameters are supported by the implementation.
func RealmParamsSupported(
params : RmiRealmParams) => boolean
begin
var impl : RmmFeatures = ImplFeatures();
if (params.flags0.lpa2 == RMI_FEATURE_TRUE
&& impl.feat_lpa2 != FEATURE_TRUE) then
return FALSE;
end
if (params.flags0.sve == RMI_FEATURE_TRUE
&& impl.feat_sve != FEATURE_TRUE) then
return FALSE;
end
if (params.flags0.pmu == RMI_FEATURE_TRUE
&& impl.feat_pmu != FEATURE_TRUE) then
return FALSE;
end
if (params.flags0.da == RMI_FEATURE_TRUE
&& impl.feat_da != FEATURE_TRUE) then
return FALSE;
end
if (params.s2sz > impl.max_ipa_width) then
return FALSE;
end
if (params.sve_vl > impl.max_sve_vl) then
return FALSE;
end
if (params.num_bps == 0
|| params.num_bps + 1 > impl.num_bps) then
return FALSE;
end
if (params.num_wps == 0
|| params.num_wps + 1 > impl.num_wps) then
return FALSE;
end
if (params.pmu_num_ctrs > impl.pmu_num_ctrs) then
return FALSE;
end
if (params.hash_algo == RMI_HASH_SHA_256
&& impl.feat_sha_256 != FEATURE_TRUE) then
return FALSE;
end
if (params.hash_algo == RMI_HASH_SHA_512
&& impl.feat_sha_512 != FEATURE_TRUE) then
return FALSE;
end
if (params.num_aux_planes > impl.max_num_aux_planes) then
return FALSE;
end
if (params.num_aux_planes > 0) then
if (params.flags1.rtt_tree_pp == RMI_FEATURE_FALSE
&& impl.plane_rtt == PLANE_RTT_AUX) then
return FALSE;
end
if (params.flags1.rtt_tree_pp == RMI_FEATURE_TRUE
&& impl.plane_rtt == PLANE_RTT_SINGLE) then
return FALSE;
end
end
return TRUE;
end
14.56 RealmRttBaseEqual
function
Returns TRUE if RTT base values of realm match the
provided values.
func RealmRttBaseEqual(
realm : RmmRealm,
rtt_base : Address,
aux_rtt_base : array[3] of Address) => boolean
begin
if (realm.rtt_base[0] != rtt_base) then
return FALSE;
end
for i = 0 to 2 do
if (realm.rtt_base[i + 1] != aux_rtt_base[i]) then
return FALSE;
end
end
return TRUE;
end
14.57 RealmVmidEqual RealmRttBaseEqual function
Returns TRUE if RTT base values of realm match the
provided values.
func RealmVmidEqualRealmRttBaseEqual( realm : RmmRealm, rtt_base : Address, aux_rtt_base : array[3] of Address) => boolean begin if (realm.rtt_base[0] != rtt_base) then return FALSE; end for i = 0 to 2 do if (realm.rtt_base[i + 1] != aux_rtt_base[i]) then return FALSE; end end return TRUE; end
14.58 RealmVmidEqual function
Returns TRUE if RTT base values of realm match the
provided values.
func RealmVmidEqual( realm : RmmRealm, vmid : bits(16), aux_vmid : array[3] of bits(16)) => boolean begin if (realm.vmid[0] != vmid) then return FALSE; end for i = 0 to 2 do if (realm.vmid[i + 1] != aux_vmid[i]) then return FALSE; end end return TRUE; end
14.5859 RecAt function
Returns the REC object located at physical address
addr.
func RecAt(
addr : Address) => RmmRec
See also:
- Section 2.3
14.5960 RecAuxCount function
Returns the number of auxiliary Granules required for a REC in the
Realm described by rd.
The return value is guaranteed not to be greater than 16.
For a given Realm, this function always returns the same value.
func RecAuxCount(
rd : Address) => integer
14.6061 RecFromMpidr function
Returns the REC object identified by the specified MPIDR value, in the current Realm.
func RecFromMpidr(
mpidr : bits(64)) => RmmRec
14.6162 RecIndex function
Returns the REC index which corresponds to mpidr.
func RecIndex(
mpidr : RmiRecMpidr) => integer
begin
return (UInt(mpidr.aff0)
+ 16 * UInt(mpidr.aff1)
+ 16 * 256 * UInt(mpidr.aff2)
+ 16 * 256 * 256 * UInt(mpidr.aff3));
end
See also:
- Section 2.3.3
14.6263 RecRipasResponseToRsi function
Returns response to RIPAS change request.
func RecRipasResponseToRsi(
rec : RmmRec) => RsiResponse
begin
if ((rec.ripas_value == RAM)
&& (rec.ripas_addr != rec.ripas_top)
&& (rec.ripas_response == REJECT)) then
return RSI_REJECT;
end
return RSI_ACCEPT;
end
See also:
- Section 5.4
14.6364 RecS2APResponseToRsi function
Returns response to S2AP change request.
func RecS2APResponseToRsi(
rec : RmmRec) => RsiResponse
begin
if ((rec.s2ap_addr != rec.s2ap_top)
&& (rec.s2ap_response == REJECT)) then
return RSI_REJECT;
end
return RSI_ACCEPT;
end
See also:
- Section 10.3.2.4
14.6465 RemExtend function
Extend REM, using size LSBs from new_value,
with the remaining bits zero-padded to form a 512-bit value.
func RemExtend(
hash_algo : RmmHashAlgorithm,
old_value : RmmRealmMeasurement,
new_value : RmmRealmMeasurement,
size : integer) => RmmRealmMeasurement
See also:
- Section 7.1.2
14.66 RimExtendDataResultEqual function
Returns TRUE if command result matches the stated value.
func ResultEqual( result : RmiCommandReturnCode, status : RmiStatusCode) => boolean
func ResultEqual( result : RmiCommandReturnCode, status : RmiStatusCode, index : integer) => boolean
14.67 RimExtendData function
Extend RIM with contribution from DATA creation.
func RimExtendData(
realm : RmmRealm,
ipa : Address,
data : Address,
flags : RmiDataFlags) => RmmRealmMeasurement
See also:
- Section 15.3.1.4
14.6768 RimExtendRec function
Extend RIM with contribution from REC creation.
func RimExtendRec(
realm : RmmRealm,
params : RmiRecParams) => RmmRealmMeasurement
See also:
- Section 15.3.28.4
14.6869 RimExtendRipas function
Extend RIM with contribution from RIPAS change for an IPA range.
func RimExtendRipas(
realm : RmmRealm,
base : Address,
top : Address,
level : integer) => RmmRealmMeasurement
begin
var rim = realm.measurements[0];
var size = RttLevelSize(level);
var addr = base;
while (UInt(addr) < UInt(top)) do
rim = RimExtendRipasForEntry(rim, addr, level);
addr = ToAddress(UInt(addr) + size);
end
return rim;
end
See also:
- Section 15.3.41.4
14.70 RimInit RimExtendRipasForEntry function
Extend RIM with contribution from RIPAS change for a single RTT entry.
func RimExtendRipasForEntry( rim : RmmRealmMeasurement, ipa : Address, level : integer) => RmmRealmMeasurement
14.71 RimInit function
Initialize RIM.
func RimInit(
hash_algo : RmmHashAlgorithm,
params : RmiRealmParams) => RmmRealmMeasurement
See also:
- Section 15.3.25.4
14.72 RmiAddressRangesEqual16 RipasToRmi function
Encodes a RIPAS value.
func RipasToRmi( ripas : RmmRipas) => RmiRipas begin case ripas of when EMPTY => return RMI_EMPTY; when RAM => return RMI_RAM; when DESTROYED => return RMI_DESTROYED; when DEV => return RMI_DEV; end end
14.73 RmiAddressRangesEqual16 function
Returns TRUE if the first count entries in two arrays of
address ranges are equal.
func RmiAddressRangesEqual16(
ranges1 : array [16] of RmmAddressRange,
ranges2 : array [16] of RmiAddressRange,
count : integer) => boolean
begin
assert 0 <= count && count <= 16;
for i = 0 to count - 1 do
if ranges1[i].base != ranges2[i].base then
return FALSE;
end
if ranges1[i].top != ranges2[i].top then
return FALSE;
end
end
return TRUE;
end
14.7374 RmiAddressRangesEqual4 function
Returns TRUE if the first count entries in two arrays of
address ranges are equal.
func RmiAddressRangesEqual4(
ranges1 : array [4] of RmmAddressRange,
ranges2 : array [4] of RmiAddressRange,
count : integer) => boolean
begin
assert 0 <= count && count <= 4;
for i = 0 to count - 1 do
if ranges1[i].base != ranges2[i].base then
return FALSE;
end
if ranges1[i].top != ranges2[i].top then
return FALSE;
end
end
return TRUE;
end
14.7475 RmiDevCommDataAt function
Returns device communication data structure stored at physical
address addr.
If the PAS of addr is not NS, the return value is unknown.
func RmiDevCommDataAt(
addr : Address) => RmiDevCommData
14.7576 RmiFeatureRegister0Decode function
Decode RmiFeatureRegister0 value.
func RmiFeatureRegister0Decode(
value : bits(64)) => RmiFeatureRegister0
14.7677 RmiFeatureRegisterEncode function
Encode feature register.
func RmiFeatureRegisterEncode(
index : integer) => bits(64)
begin
var impl : RmmFeatures = ImplFeatures();
var result : bits(64) = Zeros();
if (index == 0) then
var reg : RmiFeatureRegister0;
reg.S2SZ = impl.max_ipa_width;
reg.LPA2 = FeatureToRmi(impl.feat_lpa2);
reg.SVE = FeatureToRmi(impl.feat_sve);
reg.SVE_VL = impl.max_sve_vl;
assert impl.num_bps >= 2 && impl.num_bps <= 2^6;
reg.NUM_BPS = impl.num_bps - 1;
assert impl.num_wps >= 2 && impl.num_wps <= 2^6;
reg.NUM_WPS = impl.num_wps - 1;
reg.PMU = FeatureToRmi(impl.feat_pmu);
reg.PMU_NUM_CTRS = impl.pmu_num_ctrs;
reg.HASH_SHA_256 = FeatureToRmi(impl.feat_sha_256);
reg.HASH_SHA_512 = FeatureToRmi(impl.feat_sha_512);
reg.DA = FeatureToRmi(impl.feat_da);
case impl.plane_rtt of
when PLANE_RTT_AUX => reg.PLANE_RTT = RMI_PLANE_RTT_AUX;
when PLANE_RTT_AUX_SINGLE => reg.PLANE_RTT = RMI_PLANE_RTT_AUX_SINGLE;
when PLANE_RTT_SINGLE => reg.PLANE_RTT = RMI_PLANE_RTT_SINGLE;
end
reg.MAX_NUM_AUX_PLANES = impl.max_num_aux_planes;
reg.MAX_RECS_ORDER = impl.max_recs_order;
assert impl.gicv3_num_lrs >= 1 && impl.gicv3_num_lrs <= 2^4;
reg.GICV3_NUM_LRS = impl.gicv3_num_lrs - 1;
// Omitted: encode reg into bits(64) value
end
if (index == 1) then
var reg : RmiFeatureRegister1;
reg.MAX_MECID = impl.max_mecid;
// Omitted: encode reg into bits(64) value
end
return result;
end
14.7778 RmiPdevEventIsValid function
Returns TRUE if ev is a valid encoding, and the event is
supported by pdev.
func RmiPdevEventIsValid(
ev : RmiPdevEvent) => boolean
begin
return (ev == RMI_IDE_KEY_REFRESH);
end
14.7879 RmiPdevFlagsDecode function
Decode RmiPdevFlags value.
func RmiPdevFlagsDecode(
value : bits(64)) => RmiPdevFlags
14.7980 RmiPdevParamsAt function
Returns PDEV parameters stored at physical address
addr.
If the PAS of addr is not NS, the return value is unknown.
func RmiPdevParamsAt(
addr : Address) => RmiPdevParams
14.81 RmiRealmParamsAtRmiPdevParamsIsValid function
Returns TRUE if the memory location contains a valid encoding of the RmiPdevParams type and all the following are true:
- The device identifier is valid
- The device identifier is not equal to the device identifier of another PDEV
- The Root Port identifier is valid
- The IDE stream identifier is valid
- The RID range is valid
- The RID range does not overlap the RID range of another PDEV
- The base and top of every address range is aligned to the size of a Granule
- Every address range falls within a memory range permitted by the system
- None of the address ranges overlaps another address range for this PDEV
- None of the address ranges overlaps an address range for another PDEV
func RmiPdevParamsIsValid( addr : Address) => boolean
14.82 RmiRealmParamsAt function
Returns Realm parameters stored at physical address
addr.
If the PAS of addr is not NS, the return value is unknown.
func RmiRealmParamsAt(
addr : Address) => RmiRealmParams
See also:
- Section 2.1.6
14.83 RmiRecParamsAt RmiRealmParamsIsValid function
Returns TRUE if the memory location contains a valid encoding of the RmiRealmParams type.
func RmiRealmParamsIsValid( addr : Address) => boolean
14.84 RmiRecParamsAt function
Returns REC parameters stored at physical address
addr.
If the PAS of addr is not NS, the return value is unknown.
func RmiRecParamsAt(
addr : Address) => RmiRecParams
14.8485 RmiRecRunAt function
Returns the RecRun object stored at physical address
addr.
func RmiRecRunAt(
addr : Address) => RmiRecRun
14.8586 RmiVdevFlagsDecode function
Decode RmiVdevFlags value.
func RmiVdevFlagsDecode(
value : bits(64)) => RmiVdevFlags
14.8687 RmiVdevParamsAt function
Returns VDEV parameters stored at physical address
addr.
If the PAS of addr is not NS, the return value is unknown.
func RmiVdevParamsAt(
addr : Address) => RmiVdevParams
14.88 RsiDeviceInfoAt RmiVdevParamsIsValid function
Returns device configuration stored at IPA addr, mapped in the current RealmTRUE if the memory location contains a valid encoding of the RmiPdevParams type.
func RsiDeviceInfoAtRmiVdevParamsIsValid( addr : Address) => RsiDeviceInfoboolean
14.89 RsiDeviceMeasurementsParamsAt RsiDeviceInfoAt function
Returns device configuration stored at IPA addr, mapped
in the current Realm.
func RsiDeviceInfoAt( addr : Address) => RsiDeviceInfo
14.90 RsiDeviceMeasParamsAt function
Returns RDEV measurement parameters stored at IPA
addr.
func RsiDeviceMeasurementsParamsAtRsiDeviceMeasParamsAt( addr : Address) => RsiDeviceMeasurementsParams
14.9091 RsiFeatureRegisterEncode function
Encode feature register.
func RsiFeatureRegisterEncode(
index : integer) => bits(64)
begin
var impl : RmmFeatures = ImplFeatures();
var result : bits(64) = Zeros();
if (index == 0) then
var reg : RsiFeatureRegister0;
reg.DA = FeatureToRsi(impl.feat_da);
// Omitted: set reg.MRO depending on whether platform
// implements FEAT_S2PIE
// Omitted: encode reg into bits(64) value
end
return result;
end
14.92 RsiPlaneRunAtRsiHostCallAt function
Returns Host call data stored at IPA addr, mapped in the
current Realm.
func RsiHostCallAt( addr : Address) => RsiHostCall
14.93 RsiPlaneRunAt function
Returns the PlaneRun object stored at IPA addr.
func RsiPlaneRunAt(
realm : RmmRealm,
addr : Address) => RsiPlaneRun
14.94 RttAllEntriesContiguousRsiRealmConfigAt function
Returns Realm configuration stored at IPA addr, mapped
in the current Realm.
func RsiRealmConfigAt( addr : Address) => RsiRealmConfig
14.95 RttAllEntriesContiguous function
Returns TRUE if all entries in the RTT at address rtt at
level level have contiguous output addresses, starting with
addr.
func RttAllEntriesContiguous(
rtt : RmmRtt,
addr : Address,
level : integer) => boolean
See also:
- Section 5.5
14.9596 RttAllEntriesRipas function
Returns TRUE if all entries in the RTT at address rtt
have RIPAS ripas.
func RttAllEntriesRipas(
rtt : RmmRtt,
ripas : RmmRipas) => boolean
14.9697 RttAllEntriesState function
Returns TRUE if all entries in the RTT at address rtt
have state state.
func RttAllEntriesState(
rtt : RmmRtt,
state : RmmRttEntryState) => boolean
See also:
- Section 5.5
14.9798 RttAt function
Returns the RTT at address rtt.
func RttAt(
addr : Address) => RmmRtt
14.9899 RttConfigIsValid function
Returns TRUE if the RTT configuration values provided are self-consistent and are supported by the platform.
func RttConfigIsValid(
ipa_width : integer,
rtt_level_start : integer,
rtt_num_start : integer) => boolean
See also:
- Section 5.5
14.99100 RttDescriptorDecode function
Decode an RTT descriptor.
func RttDescriptorDecode(
desc : bits(64)) => RmmRttEntry
14.100101 RttDescriptorIsValidForUnprotected function
Returns TRUE if, within the descriptor desc, all of the
following are true:
- All fields which are Host-controlled Unprotected RTT attributes are set to architecturally valid values.
- All fields which are not Host-controlled Unprotected RTT attributes are set to zero.
func RttDescriptorIsValidForUnprotected(
desc : bits(64)) => boolean
See also:
- Section 5.5.11.3
14.101102 RttEntriesInRangeRipas function
Returns TRUE if all entries in the RTT at address rtt at
level level, within IPA range [base, top), have RIPAS
ripas.
func RttEntriesInRangeRipas(
rtt : RmmRtt,
level : integer,
base : Address,
top : Address,
ripas : RmmRipas) => boolean
14.102103 RttEntryAt function
Returns the ith entry in the RTT at address
rtt.
func RttEntryAt(
rtt : Address,
i : integer) => RmmRttEntry
See also:
- Section 5.5
14.103104 RttEntryIndex function
Returns the index of the entry in a level level RTT
which is identified by addr.
func RttEntryIndex(
addr : Address,
level : integer) => integer
See also:
- Section 5.5
14.105 RttFold RttEntryStateToRmi function
Encodes the state of an RTTE.
func RttEntryStateToRmi( state : RmmRttEntryState) => RmiRttEntryState begin case state of when UNASSIGNED => return RMI_UNASSIGNED; when ASSIGNED => return RMI_ASSIGNED; when UNASSIGNED_NS => return RMI_UNASSIGNED; when ASSIGNED_NS => return RMI_ASSIGNED; when TABLE => return RMI_TABLE; when ASSIGNED_DEV_PRIVATE => return RMI_ASSIGNED_DEV_PRIVATE; when ASSIGNED_DEV_SHARED => return RMI_ASSIGNED_DEV_SHARED; when AUX_DESTROYED => return RMI_AUX_DESTROYED; end end
14.106 RttFold function
Returns the RTTE which results from folding the homogeneous RTT at
address rtt.
func RttFold(
rtt : RmmRtt) => RmmRttEntry
See also:
- Section 5.5.6
14.106107 RttIsHomogeneous function
Returns TRUE if the RTT at address rtt is
homogeneous.
func RttIsHomogeneous(
rtt : RmmRtt) => boolean
See also:
- Section 5.5.6
14.107108 RttIsLive function
Returns TRUE if the RTT at address rtt is live.
func RttIsLive(
rtt : RmmRtt) => boolean
14.108109 RttLevelIsBlockOrPage function
Returns TRUE if level is either a block or page RTT
level for the Realm described by rd.
func RttLevelIsBlockOrPage(
rd : Address,
level : integer) => boolean
See also:
- Section 5.5
14.109110 RttLevelIsStarting function
Returns TRUE if level is the starting level of the RTT
for the Realm described by rd.
func RttLevelIsStarting(
rd : Address,
level : integer) => boolean
See also:
- Section 5.5
14.110111 RttLevelIsValid function
Returns TRUE if level is a valid RTT level for the Realm
described by rd.
func RttLevelIsValid(
rd : Address,
level : integer) => boolean
See also:
- Section 5.5
14.111112 RttLevelSize function
Returns the size of the address space described by each entry in an RTT at level.
If level is invalid, the return value is unknown.
func RttLevelSize(
level : integer) => integer
See also:
- Section 5.5
14.112113 RttsAllProtectedEntriesRipas function
Returns TRUE if the RIPAS of all entries identified by Protected IPAs
in all of the starting-level RTT Granules is equal to
ripas.
func RttsAllProtectedEntriesRipas(
rtt_base : Address,
rtt_num_start : integer,
ripas : RmmRipas) => boolean
14.113114 RttsAllProtectedEntriesState function
Returns TRUE if the state of all entries identified by Protected IPAs
in all of the starting-level RTT Granules is equal to
state.
func RttsAllProtectedEntriesState(
rtt_base : Address,
rtt_num_start : integer,
state : RmmRttEntryState) => boolean
14.114115 RttsAllUnprotectedEntriesState function
Returns TRUE if the state of all entries identified by Unprotected
IPAs in all of the starting-level RTT Granules is equal to
state.
func RttsAllUnprotectedEntriesState(
rtt_base : Address,
rtt_num_start : integer,
state : RmmRttEntryState) => boolean
14.116 RttSkipEntriesUnlessRipasRttsGranuleState function
Inductive function which identifies the states of the starting-level RTT Granules.
This function is used in the definition of command footprint.
func RttsGranuleState( rtt_base : Address, rtt_num_start : integer)
14.117 RttSkipEntriesUnlessRipas function
Scanning rtt starting from ipa, returns the
IPA of the first entry whose RIPAS is ripas.
If no entry is found whose RIPAS is ripas, returns the
next IPA after the last entry in rtt.
The return value is aligned to the size of the address range
described by an entry at RTT level.
func RttSkipEntriesUnlessRipas(
rtt : RmmRtt,
level : integer,
ipa : Address,
ripas : RmmRipas) => Address
14.117118 RttSkipEntriesUnlessState function
Scanning rtt starting from ipa, returns the
IPA of the first entry whose state is state.
If no entry is found whose state is state, returns the
next IPA after the last entry in rtt.
The return value is aligned to the size of the address range
described by an entry at RTT level.
func RttSkipEntriesUnlessState(
rtt : RmmRtt,
level : integer,
ipa : Address,
state : RmmRttEntryState) => Address
14.118119 RttSkipEntriesWithRipas function
Scan rtt starting from base and terminating
at top.
- If stop_at_destroyed is FALSE then return IPA of the first entry whose state is TABLE.
- If stop_at_destroyed is TRUE then return IPA of the first entry whose state is TABLE or whose RIPAS is DESTROYED.
If no such entry is found, returns the smaller of:
- The next IPA after the last entry in
rtt - The
topargument.
The return value is aligned to the size of the address range
described by an entry at RTT level.
func RttSkipEntriesWithRipas(
rtt : RmmRtt,
level : integer,
base : Address,
top : Address,
stop_at_destroyed : boolean) => Address
begin
var result : Address = RttSkipEntriesUnlessState(
rtt, level, base, TABLE);
if stop_at_destroyed then
result = MinAddress(result,
RttSkipEntriesUnlessRipas(
rtt, level, base, DESTROYED));
end
result = MinAddress(result, top);
return AlignDownToRttLevel(result, level);
end
14.119120 RttSkipNonLiveEntries function
Scanning rtt starting from ipa, returns the
IPA of the first live entry.
If no live entry is found, returns the next IPA after the last entry
in rtt.
The return value is aligned to the size of the address range
described by an entry at RTT level.
func RttSkipNonLiveEntries(
rtt : RmmRtt,
level : integer,
ipa : Address) => Address
begin
var result : Address = RttSkipEntriesUnlessState(
rtt, level, ipa, ASSIGNED);
result = MinAddress(result,
RttSkipEntriesUnlessState(
rtt, level, ipa, ASSIGNED_NS));
result = MinAddress(result,
RttSkipEntriesUnlessState(
rtt, level, ipa, TABLE));
result = MinAddress(result,
RttSkipEntriesUnlessState(
rtt, level, ipa, ASSIGNED_DEV_PRIVATE));
result = MinAddress(result,
RttSkipEntriesUnlessState(
rtt, level, ipa, ASSIGNED_DEV_SHARED));
return AlignDownToRttLevel(result, level);
end
See also:
- Section 5.5.8
14.120121 RttsStateEqual function
Returns TRUE if the state of all of the starting-level RTT Granules
is equal to state.
func RttsStateEqual(
rtt_base : Address,
rtt_num_start : integer,
state : RmmGranuleState) => boolean
begin
for i = 0 to rtt_num_start - 1 do
var addr = (UInt(rtt_base) + i * RMM_GRANULE_SIZE)[(ADDRESS_WIDTH-1):0];
if (!PaIsDelegable(addr)
|| GranuleAt(addr).state != state) then
return FALSE;
end
end
return TRUE;
end
14.121122 RttWalk function
Returns the result of an RTT walk from the base of RTT tree
index owned by rd, to address
addr.
The walk does not progress beyond level.
func RttWalk(
rd : Address,
addr : Address,
level : integer,
index : integer) => RmmRttWalkResult
See also:
- Section 5.5.10
14.123 TdiIdIsFree RttWalkAnyNotAligned function
Performs one or more RTT walks within the IPA range
[base, top), on one or more RTT trees owned by
rd.
For a Realm which is configured to use an RTT per Plane, it is permitted for an implementation to either walk just one of the RTTs, or to walk all of them.
It is permitted for an implementation to perform multiple walks, at successive IPAs, on the same RTT.
If one of the walks performed terminates earlier than
level then the return value indicates the RTT index and the
IPA at which the walk was performed. In this case, the result’s “valid”
value is TRUE.
If none of the walks performed terminates earlier than
level then the result’s “valid” value is FALSE.
func RttWalkAnyNotAligned( rd : Address, base : Address, top : Address, level : integer) => RmmRttWalkNotAligned
14.124 TdiIdIsFree function
Returns TRUE if tdi_id is unused within the segment
identified by segment_id.
func TdiIdIsFree(
tdi_id : bits(64),
segment_id : bits(16)) => boolean
14.124125 ToAddress function
Convert integer to Address.
func ToAddress(value : integer) => Address begin return value[(ADDRESS_WIDTH-1):0]; end
14.126 VdevAtToBits64 function
Convert integer to Bits64.
func ToBits64(value : integer) => bits(64)
begin
return value[63:0];
end
14.127 VdevAt function
Returns the VDEV object located at physical address
addr.
func VdevAt(
addr : Address) => RmmVdev
14.128 VmidsAreFreeVdevAuxCount function
Returns the number of auxiliary Granules required for a VDEV with the specified flags.
The return value is guaranteed not to be greater than 32.
For a given flags value, this function always returns the same value.
func VdevAuxCount( pdev_flags : RmiPdevFlags, vdev_flags : RmiVdevFlags) => integer
14.129 VmidsAreFree function
Returns TRUE if vmid is unused.
func VmidsAreFree(
vmid : array[4] of bits(16)) => boolean
func VmidsAreFree(
vmid : bits(16),
aux_vmid : array [3] of bits(16)) => boolean
14.129130 VmidsAreValid function
Returns TRUE if vmid is valid on the platform.
func VmidsAreValid(
vmid : bits(16),
aux_vmid : array [3] of bits(16)) => boolean
15 Realm Management Interface
This chapter defines the interface used by the Host to manage Realms.
15.1 RMI version
This specification defines version 1.1 of the Realm Management Interface.
15.2 RMI command return codes
The return code of an RMI command is a tuple which contains status and index fields.
The status field of an RMI command return code indicates whether the command
- succeeded, or
- failed, and the reason for the failure.
If an RMI command succeeds then the status of its return code is RMI_SUCCESS.
The index field of an RMI command return code can provide additional information about the reason for a command failure. The meaning of the index field depends on the status, and is described by the following table.
| Status | Description | Meaning of index |
|---|---|---|
| RMI_SUCCESS | Command completed successfully | None: index is zero. |
| RMI_ERROR_INPUT | The value of a command input value caused the command to fail | None: index is zero. |
| RMI_ERROR_REALM | An attribute of a Realm does not match the expected value | Varies between usages. See individual commands for details. |
| RMI_ERROR_REC | An attribute of a REC does not match the expected value | None: index is zero. |
| RMI_ERROR_RTT | An RTT walk terminated before reaching the target RTT level, or reached an RTTE with an unexpected value | RTT level at which the walk terminated. |
| RMI_ERROR_RTT_AUX | RTTE in an auxiliary RTT contained an unexpected value | In some cases, indicates auxiliary RTT level at which the walk terminated. See individual commands for details. |
Multiple failure conditions in an RMI command may return the same error code - that is, the same status and index values.
If an input to an RMI command uses an invalid encoding in an enumeration Invalid encodings include:then the command fails and returns RMI_ERROR_INPUT.
Command inputs include registers and in-memory data structures.
If an input to an RMI command uses an invalidInvalid encodings include:
- using a reserved encoding then the command fails and returns RMI_ERROR_INPUT.in an enumeration
See also:
- Section 15.4.3
15.3 RMI commands
The following table summarizes the FIDs of commands in the RMI interface.
15.3.1 RMI_DATA_CREATE command
Creates a Data Granule, copying contents from a Non-secure Granule provided by the caller.
15.3.1.1 Interface
15.3.1.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000153 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| data | X2 | 63:0 | Address | PA of the target Data |
| ipa | X3 | 63:0 | Address | IPA at which the Granule will be mapped in the target Realm |
| src | X4 | 63:0 | Address | PA of the source Granule |
| flags | X5 | 63:0 | RmiDataFlags | Flags |
15.3.1.1.2 Context
The RMI_DATA_CREATE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm_pre | RmmRealm | RealmAt(rd) |
true | Realm |
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, RMM_RTT_PAGE_LEVEL, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
15.3.1.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.1.2 Failure conditions
| ID | Condition |
|---|---|
| src_align | pre: !AddrIsGranuleAligned(src) post: ResultEqual(result, RMI_ERROR_INPUT) |
| src_bound | pre: !PaIsDelegable(src) post: ResultEqual(result, RMI_ERROR_INPUT) |
| src_pas | pre: !GranuleAccessPermitted(src, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_align | pre: !AddrIsGranuleAligned(data) post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_bound | pre: !PaIsDelegable(data) post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_state | pre: GranuleAt(data).state != DELEGATED post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_bound2 | pre: ((realm.feat_lpa2 == FEATURE_FALSE) && (UInt(data) >= 2^48)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsGranuleAligned(ipa) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: !AddrIsProtected(ipa, realm_pre) post: ResultEqual(result, RMI_ERROR_INPUT) |
| realm_state | pre: realm_pre.state != REALM_NEW post: ResultEqual(result, RMI_ERROR_REALM) |
| rtt_walk | pre: walk.level < RMM_RTT_PAGE_LEVEL post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
| rtte_state | pre: walk.rtte.state != UNASSIGNED post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
15.3.1.2.1 Failure condition ordering
[rd_bound, rd_state] < [realm_state]
[rd_bound, rd_state] < [rtt_walk, rtte_state]
[ipa_bound] < [rtt_walk, rtte_state]
15.3.1.3 Success conditions
| ID | Condition |
|---|---|
| data_state | GranuleAt(data).state == DATA |
| rtte_state | walk.rtte.state == ASSIGNED |
| rtte_ripas | walk.rtte.ripas == RAM |
| rtte_addr | walk.rtte.addr == data |
| rim | realm.measurements[0] == RimExtendData( realm_pre, ipa, data, flags) |
15.3.1.4 RMI_DATA_CREATE extension of RIM
On successful execution of RMI_DATA_CREATE, the new RIM value of the target Realm is calculated by the RMM as follows:
If flags.measure == RMI_MEASURE_CONTENT then using the RHA of the target Realm, compute the hash of the contents of the DATA Granule.
Allocate an RmmMeasurementDescriptorData data structure.
Populate the measurement descriptor:
- Set the desc_type field to the descriptor type.
- Set the len field to the descriptor length.
- Set the rim field to the current RIM value of the target Realm.
- Set the ipa field to the IPA at which the DATA Granule is mapped in the target Realm.
- Set the flags field to the flags provided by the Host.
- If flags.measure == RMI_MEASURE_CONTENT then set the content field to the hash of the contents of the DATA Granule. Otherwise, set the content field to zero.
- Using the RHA of the target Realm, compute the hash of the measurement descriptor. Set the RIM of the target Realm to this value, zero filling upper bytes if the RHA output is smaller than the size of the RIM.
15.3.1.5 Footprint
| ID | Value |
|---|---|
| data_state | GranuleAt(data).state |
| rim | realm.measurements[0] |
| rtte | RttEntryAt(walk.rtt_addr, entry_idx) |
15.3.2 RMI_DATA_CREATE_UNKNOWN command
Creates a Data Granule with unknown contents.
15.3.2.1 Interface
15.3.2.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000154 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| data | X2 | 63:0 | Address | PA of the target Data |
| ipa | X3 | 63:0 | Address | IPA at which the Granule will be mapped in the target Realm |
15.3.2.1.2 Context
The RMI_DATA_CREATE_UNKNOWN command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, RMM_RTT_PAGE_LEVEL, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
15.3.2.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.2.2 Failure conditions
| ID | Condition |
|---|---|
| data_align | pre: !AddrIsGranuleAligned(data) post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_bound | pre: !PaIsDelegable(data) post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_state | pre: GranuleAt(data).state != DELEGATED post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_bound2 | pre: ((realm.feat_lpa2 == FEATURE_FALSE) && (UInt(data) >= 2^48)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsGranuleAligned(ipa) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: !AddrIsProtected(ipa, realm) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_walk | pre: walk.level < RMM_RTT_PAGE_LEVEL post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
| rtte_state | pre: walk.rtte.state != UNASSIGNED post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
15.3.2.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state]
[ipa_bound] < [rtt_walk, rtte_state]
15.3.2.3 Success conditions
| ID | Condition |
|---|---|
| data_state | GranuleAt(data).state == DATA |
| data_content | Contents of target Granule are wiped. |
| rtte_state | walk.rtte.state == ASSIGNED |
| rtte_addr | walk.rtte.addr == data |
15.3.2.4 Footprint
| ID | Value |
|---|---|
| data_state | GranuleAt(data).state |
| rtte | RttEntryAt(walk.rtt_addr, entry_idx) |
15.3.3 RMI_DATA_DESTROY command
Destroys a Data Granule.
15.3.3.1 Interface
15.3.3.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000155 |
| rd | X1 | 63:0 | Address | PA of the RD which owns the target Data |
| ipa | X2 | 63:0 | Address | IPA at which the Granule is mapped in the target Realm |
15.3.3.1.2 Context
The RMI_DATA_DESTROY command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, RMM_RTT_PAGE_LEVEL, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| walk_top | Address | RttSkipNonLiveEntries( RttAt(walk.rtt_addr), walk.level, ipa) |
false | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
15.3.3.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| data | X1 | 63:0 | Address | PA of the Data Granule which was destroyed |
| top | X2 | 63:0 | Address | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
The data output value is valid only when the command
result is RMI_SUCCESS.
The values of the result and top output
values for different command outcomes are summarized in the following
table.
| Scenario | result | top | walk.rtte.state |
|---|---|---|---|
ipa is mapped as a page |
RMI_SUCCESS | > ipa | Before execution: ASSIGNED After execution: UNASSIGNED and RIPAS is DESTROYED |
ipa is not mapped |
(RMI_ERROR_RTT, <= 3) | > ipa | UNASSIGNED |
ipa is mapped as a block |
(RMI_ERROR_RTT, 0 0 < level < 3) |
== ipa | ASSIGNED |
| RTT walk was not performed, due to any other command failure | Another error code | 0 | Unknown |
See also:
- Section 5.5.8
15.3.3.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsGranuleAligned(ipa) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: !AddrIsProtected(ipa, realm) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_walk | pre: walk.level < RMM_RTT_PAGE_LEVEL post: (ResultEqual(result, RMI_ERROR_RTT, walk.level) && (top == walk_top)) |
| rtte_state | pre: walk.rtte.state != ASSIGNED post: (ResultEqual(result, RMI_ERROR_RTT, walk.level) && (top == walk_top)) |
| aux_live | pre: AddrIsAuxLive(ipa, realm) post: ResultEqual(result, RMI_ERROR_RTT_AUX, 0) |
15.3.3.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state, aux_live]
[ipa_bound] < [rtt_walk, rtte_state, aux_live]
15.3.3.3 Success conditions
| ID | Condition |
|---|---|
| data_state | GranuleAt(walk.rtte.addr).state == DELEGATED |
| rtte_state | walk.rtte.state == UNASSIGNED |
| ripas_ram | pre: walk.rtte.ripas == RAM post: walk.rtte.ripas == DESTROYED |
| data | data == walk.rtte.addr |
| top | top == walk_top |
15.3.3.4 Footprint
| ID | Value |
|---|---|
| data_state | GranuleAt(walk.rtte.addr).state |
| rtte | RttEntryAt(walk.rtt_addr, entry_idx) |
15.3.4 RMI_DEV_MEM_MAP command
Maps device memory.
See also:
- Section 9
15.3.4.1 Interface
15.3.4.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000172 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | IPA at which the Granule will be mapped in the target Realm |
| addr | X3 | 63:0 | Address | PA of the target device memory |
15.3.4.1.2 Context
The RMI_DEV_MEM_MAP command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, RMM_RTT_PAGE_LEVEL, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| gran_state_pre | RmmGranuleState | GranuleAt(addr).state |
true | Previous Granule state |
15.3.4.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.4.2 Failure conditions
| ID | Condition |
|---|---|
| addr_align | pre: !AddrIsGranuleAligned(addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| addr_bound | pre: !PaIsDelegable(addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsGranuleAligned(ipa) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: !AddrIsProtected(ipa, realm) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_walk | pre: walk.level < RMM_RTT_PAGE_LEVEL post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
| rtte_state | pre: walk.rtte.state != UNASSIGNED post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
15.3.4.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state]
[ipa_bound] < [rtt_walk, rtte_state]
15.3.4.3 Success conditions
| ID | Condition |
|---|---|
| state_private | pre: gran_state_pre == DEV_DELEGATED_PRIVATE post: GranuleAt(addr).state == DEV_PRIVATE |
| state_shared | pre: gran_state_pre == DEV_DELEGATED_SHARED post: GranuleAt(addr).state == DEV_SHARED |
| rtte_state_private | pre: gran_state_pre == DEV_DELEGATED_PRIVATE post: walk.rtte.state == ASSIGNED_DEV_PRIVATE |
| rtte_state_shared | pre: gran_state_pre == DEV_DELEGATED_SHARED post: walk.rtte.state == ASSIGNED_DEV_SHARED |
| rtte_addr | walk.rtte.addr == addr |
15.3.4.4 Footprint
| ID | Value |
|---|---|
| state | GranuleAt(addr).state |
| rtte | RttEntryAt(walk.rtt_addr, entry_idx) |
15.3.5 RMI_DEV_MEM_UNMAP command
Unmaps device memory.
Consider how teardown of DRAM mappings (via RMI_DATA_DESTROY) composes with teardown of device memory mappings (via RMI_DEV_MEM_UNMAP). In each case, the command returns the IPA of the next live entry - but it doesn’t tell the caller whether this is DRAM or IO. How then can the caller know which of the two commands to call next, while still avoiding a (race-prone) call to RMI_RTT_READ_ENTRY?
See also:
- Section 9
15.3.5.1 Interface
15.3.5.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000173 |
| rd | X1 | 63:0 | Address | PA of the RD which owns the target device memory Granule |
| ipa | X2 | 63:0 | Address | IPA at which the Granule is mapped in the target Realm |
15.3.5.1.2 Context
The RMI_DEV_MEM_UNMAP command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, RMM_RTT_PAGE_LEVEL, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| rtte_state_pre | RmmRttEntryState | walk.rtte.state |
true | RTT entry state |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| walk_top | Address | RttSkipNonLiveEntries( RttAt(walk.rtt_addr), walk.level, ipa) |
false | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
15.3.5.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| io | X1 | 63:0 | Address | PA of the device memory Granule which was unmapped |
| top | X2 | 63:0 | Address | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
15.3.5.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsGranuleAligned(ipa) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: !AddrIsProtected(ipa, realm) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_walk | pre: walk.level < RMM_RTT_PAGE_LEVEL post: (ResultEqual(result, RMI_ERROR_RTT, walk.level) && (top == walk_top)) |
| rtte_state | pre: (walk.rtte.state != ASSIGNED_DEV_PRIVATE && walk.rtte.state != ASSIGNED_DEV_SHARED) post: (ResultEqual(result, RMI_ERROR_RTT, walk.level) && (top == walk_top)) |
15.3.5.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state]
[ipa_bound] < [rtt_walk, rtte_state]
15.3.5.3 Success conditions
| ID | Condition |
|---|---|
| comm_state_private | pre: rtte_state_pre == ASSIGNED_DEV_PRIVATE post: GranuleAt(walk.rtte.addr).state == DEV_DELEGATED_PRIVATE |
| comm_state_shared | pre: rtte_state_pre == ASSIGNED_DEV_SHARED post: GranuleAt(walk.rtte.addr).state == DEV_DELEGATED_SHARED |
| rtte_state | walk.rtte.state == UNASSIGNED |
| ripas_ram | pre: walk.rtte.ripas == DEV post: walk.rtte.ripas == DESTROYED |
| io | io == walk.rtte.addr |
| top | top == walk_top |
15.3.5.4 Footprint
| ID | Value |
|---|---|
| comm_state | GranuleAt(walk.rtte.addr).state |
| rtte | RttEntryAt(walk.rtt_addr, entry_idx) |
15.3.6 RMI_FEATURES command
Read feature register.
The following table indicates which feature register is returned depending on the index provided.
| Index | Feature register |
|---|---|
| 0 | RMI feature register 0 |
| 1 | RMI feature register 1 |
See also:
- Section 3
15.3.6.1 Interface
15.3.6.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000165 |
| index | X1 | 63:0 | UInt64 | Feature register index |
15.3.6.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| value | X1 | 63:0 | Bits64 | Feature register value |
15.3.6.2 Failure conditions
The RMI_FEATURES command does not have any failure conditions.
15.3.6.3 Success conditions
| ID | Condition |
|---|---|
| value | value == RmiFeatureRegisterEncode(index) |
15.3.6.4 Footprint
The RMI_FEATURES command does not have any footprint.
15.3.7 RMI_GRANULE_DELEGATE command
Delegates a Granule.
15.3.7.1 Interface
15.3.7.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000151 |
| addr | X1 | 63:0 | Address | PA of the target Granule |
15.3.7.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.7.2 Failure conditions
| ID | Condition |
|---|---|
| gran_align | pre: !AddrIsGranuleAligned(addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| gran_bound | pre: !PaIsDelegable(addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| gran_state | pre: GranuleAt(addr).state != UNDELEGATED post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.7.2.1 Failure condition ordering
The RMI_GRANULE_DELEGATE command does not have any failure condition orderings.
15.3.7.3 Success conditions
| ID | Condition |
|---|---|
| gran_state | GranuleAt(addr).state == DELEGATED |
| gran_gpt | GranuleAt(addr).gpt == GPT_REALM |
15.3.7.4 Footprint
15.3.8 RMI_GRANULE_DEV_DELEGATE command
Delegate a Granule of device memory.
See also:
- Section 9
15.3.8.1 Interface
15.3.8.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000170 |
| addr | X1 | 63:0 | Address | PA of the target Granule |
| flags | X2 | 63:0 | RmiDevDelegateFlags | Flags |
15.3.8.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.8.2 Failure conditions
| ID | Condition |
|---|---|
| gran_align | pre: !AddrIsGranuleAligned(addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| gran_bound | pre: !PaIsDelegable(addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| gran_state | pre: GranuleAt(addr).state != DEV_UNDELEGATED post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.8.2.1 Failure condition ordering
The RMI_GRANULE_DEV_DELEGATE command does not have any failure condition orderings.
15.3.8.3 Success conditions
| ID | Condition |
|---|---|
| state_private | pre: flags.share == RMI_DEV_MEM_PRIVATE post: GranuleAt(addr).state == DEV_DELEGATED_PRIVATE |
| gpt_private | pre: flags.share == RMI_DEV_MEM_PRIVATE post: GranuleAt(addr).gpt == GPT_REALM |
| state_shared | pre: flags.share == RMI_DEV_MEM_SHARED post: GranuleAt(addr).state == DEV_DELEGATED_SHARED |
| gpt_shared | pre: flags.share == RMI_DEV_MEM_SHARED post: GranuleAt(addr).gpt == GPT_AAP |
15.3.8.4 Footprint
15.3.9 RMI_GRANULE_DEV_UNDELEGATE command
Undelegate a Granule of device memory.
See also:
- Section 9
15.3.9.1 Interface
15.3.9.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000171 |
| addr | X1 | 63:0 | Address | PA of the target Granule |
15.3.9.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.9.2 Failure conditions
| ID | Condition |
|---|---|
| gran_align | pre: !AddrIsGranuleAligned(addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| gran_bound | pre: !PaIsDelegable(addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| gran_state | pre: (GranuleAt(addr).state != DEV_DELEGATED_PRIVATE && GranuleAt(addr).state != DEV_DELEGATED_SHARED) post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.9.2.1 Failure condition ordering
The RMI_GRANULE_DEV_UNDELEGATE command does not have any failure condition orderings.
15.3.9.3 Success conditions
| ID | Condition |
|---|---|
| gpt | GranuleAt(addr).gpt != GPT_REALM |
| state | GranuleAt(addr).state == DEV_UNDELEGATED |
15.3.9.4 Footprint
15.3.10 RMI_GRANULE_UNDELEGATE command
Undelegates a Granule.
15.3.10.1 Interface
15.3.10.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000152 |
| addr | X1 | 63:0 | Address | PA of the target Granule |
15.3.10.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.10.2 Failure conditions
| ID | Condition |
|---|---|
| gran_align | pre: !AddrIsGranuleAligned(addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| gran_bound | pre: !PaIsDelegable(addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| gran_state | pre: GranuleAt(addr).state != DELEGATED post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.10.2.1 Failure condition ordering
The RMI_GRANULE_UNDELEGATE command does not have any failure condition orderings.
15.3.10.3 Success conditions
| ID | Condition |
|---|---|
| gran_gpt | GranuleAt(addr).gpt != GPT_REALM |
| gran_state | GranuleAt(addr).state == UNDELEGATED |
| gran_content | Contents of target Granule are wiped. |
See also:
- Section 2.2.4
15.3.10.4 Footprint
15.3.11 RMI_MEC_SET_PRIVATE command
Change state of a MEC to Private.
15.3.11.1 Interface
15.3.11.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400018D |
| mecid | X1 | 63:0 | Bits64 | MECID |
15.3.11.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.11.2 Failure conditions
| ID | Condition |
|---|---|
| mecid_bound | pre: UInt(mecid) > UInt(ImplFeatures().max_mecid) post: ResultEqual(result, RMI_ERROR_INPUT) |
| state | pre: MecState(mecid) != MEC_STATE_SHARED post: ResultEqual(result, RMI_ERROR_INPUT) |
| members | pre: MecMembers(mecid) != 0 post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.11.2.1 Failure condition ordering
The RMI_MEC_SET_PRIVATE command does not have any failure condition orderings.
15.3.11.3 Success conditions
| ID | Condition |
|---|---|
| mec_state | MecState(mecid) == MEC_STATE_PRIVATE_UNASSIGNED |
15.3.11.4 Footprint
The RMI_MEC_SET_PRIVATE command does not have any footprint.
15.3.12 RMI_MEC_SET_SHARED command
Change state of a MEC to Shared.
15.3.12.1 Interface
15.3.12.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400018C |
| mecid | X1 | 63:0 | Bits64 | MECID |
15.3.12.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.12.2 Failure conditions
| ID | Condition |
|---|---|
| mecid_bound | pre: UInt(mecid) > UInt(ImplFeatures().max_mecid) post: ResultEqual(result, RMI_ERROR_INPUT) |
| state | pre: MecState(mecid) != MEC_STATE_PRIVATE_UNASSIGNED post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.12.2.1 Failure condition ordering
The RMI_MEC_SET_SHARED command does not have any failure condition orderings.
15.3.12.3 Success conditions
| ID | Condition |
|---|---|
| mec_state | MecState(mecid) == MEC_STATE_SHARED |
15.3.12.4 Footprint
The RMI_MEC_SET_SHARED command does not have any footprint.
15.3.13 RMI_PDEV_ABORT command
Abort device communication associated with a PDEV.
See also:
- Section 9
15.3.13.1 Interface
15.3.13.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000174 |
| pdev_ptr | X1 | 63:0 | Address | PA of the PDEV |
15.3.13.1.2 Context
The RMI_PDEV_ABORT command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| pdev | RmmPdev | PdevAt(pdev_ptr) |
false | PDEV |
| pdev_state_pre | RmmPdevState | pdev.state |
true | Previous state |
15.3.13.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.13.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_gran_state | pre: GranuleAt(pdev_ptr).state != PDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_state | pre: (pdev.state != PDEV_NEW && pdev.state != PDEV_HAS_KEY && pdev.state != PDEV_COMMUNICATING) post: ResultEqual(result, RMI_ERROR_DEVICE) |
15.3.13.2.1 Failure condition ordering
[da_supp] < [pdev_align, pdev_bound, pdev_gran_state]
[pdev_gran_state] < [pdev_state]
15.3.13.3 Success conditions
| ID | Condition |
|---|---|
| state | pre: pdev_state_pre == PDEV_COMMUNICATING post: pdev.state == PDEV_READY |
| comm_state | pdev.comm_state == DEV_COMM_IDLE |
15.3.13.4 Footprint
| ID | Value |
|---|---|
| state | pdev.state |
| comm_state | pdev.comm_state |
15.3.14 RMI_PDEV_AUX_COUNT command
Get number of auxiliary Granules required for a PDEV.
15.3.14.1 Interface
15.3.14.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000156 |
| flags | X1 | 63:0 | Bits64 | PDEV flags |
15.3.14.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| aux_count | X1 | 63:0 | UInt64 | Number of auxiliary Granules required for a PDEV |
15.3.14.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
15.3.14.3 Success conditions
| ID | Condition |
|---|---|
| aux_count | aux_count == PdevAuxCount(RmiPdevFlagsDecode(flags)) |
15.3.14.4 Footprint
The RMI_PDEV_AUX_COUNT command does not have any footprint.
15.3.15 RMI_PDEV_COMMUNICATE command
Perform device communication associated with a PDEV.
See also:
- Section 9
15.3.15.1 Interface
15.3.15.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000175 |
| pdev_ptr | X1 | 63:0 | Address | PA of the PDEV |
| data_ptr | X2 | 63:0 | Address | PA of the communication data structure |
15.3.15.1.2 Context
The RMI_PDEV_COMMUNICATE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| pdev | RmmPdev | PdevAt(pdev_ptr) |
false | PDEV |
| pdev_state_pre | RmmPdevState | PdevAt(pdev_ptr).state |
true | PDEV previous state |
| data | RmiDevCommData | RmiDevCommDataAt(data_ptr) |
false | Device communication object |
15.3.15.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.15.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_gran_state | pre: GranuleAt(pdev_ptr).state != PDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_align | pre: !AddrIsGranuleAligned(data_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_bound | pre: !PaIsDelegable(data_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_pas | pre: !GranuleAccessPermitted(data_ptr, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| req_align | pre: !AddrIsGranuleAligned(data.enter.req_addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| req_bound | pre: !PaIsDelegable(data.enter.req_addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| req_pas | pre: !GranuleAccessPermitted(data.enter.req_addr, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| resp_align | pre: !AddrIsGranuleAligned(data.enter.resp_addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| resp_bound | pre: !PaIsDelegable(data.enter.resp_addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| resp_pas | pre: !GranuleAccessPermitted(data.enter.resp_addr, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| resp_len | pre: data.enter.resp_len > RMM_GRANULE_SIZE post: ResultEqual(result, RMI_ERROR_INPUT) |
| comm_state | pre: (pdev.comm_state == DEV_COMM_IDLE || pdev.comm_state == DEV_COMM_ERROR) post: ResultEqual(result, RMI_ERROR_DEVICE) |
15.3.15.2.1 Failure condition ordering
[da_supp] < [pdev_align, pdev_bound, pdev_gran_state, data_align,
data_bound, data_pas, req_align, req_bound, req_pas, resp_align,
resp_bound, resp_pas, resp_len]
[pdev_gran_state] < [comm_state]
15.3.15.3 Success conditions
| ID | Condition |
|---|---|
| comm_state | pdev.comm_state == DeviceCommunicate(pdev, data) |
| error | pre: (DeviceCommunicate(pdev, data) == DEV_COMM_ERROR && pdev.state != PDEV_STOPPING) post: pdev.state == PDEV_ERROR |
| new | pre: (DeviceCommunicate(pdev, data) == DEV_COMM_IDLE && pdev_state_pre == PDEV_NEW) post: pdev.state == PDEV_NEEDS_KEY |
| has_key | pre: (DeviceCommunicate(pdev, data) == DEV_COMM_IDLE && pdev_state_pre == PDEV_HAS_KEY) post: pdev.state == PDEV_READY |
| ready | pre: (DeviceCommunicate(pdev, data) == DEV_COMM_IDLE && pdev_state_pre == PDEV_READY) post: pdev.state == PDEV_READY |
| stopped | pre: (DeviceCommunicate(pdev, data) != DEV_COMM_ACTIVE && pdev_state_pre == PDEV_STOPPING) post: pdev.state == PDEV_STOPPED |
| communicating | pre: (DeviceCommunicate(pdev, data) == DEV_COMM_IDLE && pdev_state_pre == PDEV_COMMUNICATING) post: pdev.state == PDEV_READY |
| ide_resetting | pre: (DeviceCommunicate(pdev, data) == DEV_COMM_IDLE && pdev_state_pre == PDEV_IDE_RESETTING) post: pdev.state == PDEV_READY |
15.3.15.4 Footprint
| ID | Value |
|---|---|
| state | pdev.state |
| comm_state | pdev.comm_state |
15.3.16 RMI_PDEV_CREATE command
Create a PDEV.
See also:
- Section 9
15.3.16.1 Interface
15.3.16.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000176 |
| pdev_ptr | X1 | 63:0 | Address | PA of the PDEV |
| params_ptr | X2 | 63:0 | Address | PA of PDEV parameters |
15.3.16.1.2 Context
The RMI_PDEV_CREATE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| pdev | RmmPdev | PdevAt(pdev_ptr) |
false | PDEV |
| params | RmiPdevParams | RmiPdevParamsAt(params_ptr) |
false | PDEV parameters |
15.3.16.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.16.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_state | pre: GranuleAt(pdev_ptr).state != DELEGATED post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_align | pre: !AddrIsGranuleAligned(params_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_bound | pre: !PaIsDelegable(params_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_pas | pre: !GranuleAccessPermitted(params_ptr, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_valid | pre: !RmiPdevParamsIsValid(params_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| num_aux | pre: params.num_aux != PdevAuxCount(params.flags) post: ResultEqual(result, RMI_ERROR_INPUT) |
| aux_align | pre: !AuxAligned32(params.aux, params.num_aux) post: ResultEqual(result, RMI_ERROR_INPUT) |
| aux_alias | pre: AuxAlias32(pdev_ptr, params.aux, params.num_aux) post: ResultEqual(result, RMI_ERROR_INPUT) |
| aux_state | pre: !AuxStateEqual32( params.aux, params.num_aux, DELEGATED) post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.16.2.1 Failure condition ordering
[da_supp] < [pdev_align, pdev_bound, pdev_state, params_align,
params_bound, params_pas, params_valid, num_aux, aux_align,
aux_alias, aux_state]
15.3.16.3 Success conditions
| ID | Condition |
|---|---|
| gran_state | GranuleAt(pdev_ptr).state == PDEV |
| pdev_id | pdev.pdev_id == params.pdev_id |
| spdmprot_config | Equal(pdev.spdmprot_config, params.flags.spdmprot_config) |
| segment_id | pdev.segment_id == params.segment_id |
| root_id | pdev.root_id == params.root_id |
| cert_id | pdev.cert_id == params.cert_id |
| rid_base | pdev.rid_base == params.rid_base |
| rid_top | pdev.rid_top == params.rid_top |
| hash_algo | Equal(pdev.hash_algo, params.hash_algo) |
| ncoh_sidide_sid | pdev.ncoh_sidide_sid == params.ncoh_sidide_sid |
| ncoh_num_addr_rangeiocoh_num_addr_range | pdev.ncoh_num_addr_rangeiocoh_num_addr_range == params.ncoh_num_addr_rangeiocoh_num_addr_range |
| ncoh_addr_rangeiocoh_addr_range | RmiAddressRangesEqual16( pdev.ncoh_addr_rangeiocoh_addr_range, params.ncoh_addr_rangeiocoh_addr_range, params.ncoh_num_addr_rangeiocoh_num_addr_range) |
| coh_sidfcoh_num_addr_range | pdev.coh_sidfcoh_num_addr_range == params.coh_sidfcoh_num_addr_range |
| coh_num_addr_rangefcoh_addr_range | pdev.coh_num_addr_range == params.coh_num_addr_range coh_addr_range RmiAddressRangesEqual4( pdev.coh_addr_rangefcoh_addr_range, params.coh_addr_rangefcoh_addr_range, params.coh_num_addr_rangefcoh_num_addr_range) |
| state | pdev.state == PDEV_NEW |
| comm_state | pdev.comm_state == DEV_COMM_PENDING |
| num_vdevs | pdev.num_vdevs == 0 |
| aux | AuxEqual32( pdev.aux, params.aux, PdevAuxCount(params.flags)) |
| num_aux | pdev.num_aux == PdevAuxCount(params.flags) |
| aux_state | AuxStateEqual32( pdev.aux, PdevAuxCount(params.flags), PDEV_AUX) |
15.3.16.4 Footprint
| ID | Value |
|---|---|
| state | GranuleAt(pdev_ptr).state |
| aux_state | AuxStates( pdev.aux, PdevAuxCount(params.flags)) |
15.3.17 RMI_PDEV_DESTROY command
Destroy a PDEV.
See also:
- Section 9
15.3.17.1 Interface
15.3.17.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000177 |
| pdev_ptr | X1 | 63:0 | Address | PA of the PDEV |
15.3.17.1.2 Context
The RMI_PDEV_DESTROY command operates on the following context.
15.3.17.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.17.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_gran_state | pre: GranuleAt(pdev_ptr).state != PDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_state | pre: pdev_pre.state != PDEV_STOPPED post: ResultEqual(result, RMI_ERROR_DEVICE) |
15.3.17.2.1 Failure condition ordering
[pdev_gran_state] < [pdev_state]
[da_supp] < [pdev_align, pdev_bound, pdev_gran_state, pdev_state]
15.3.17.3 Success conditions
| ID | Condition |
|---|---|
| gran_state | GranuleAt(pdev_ptr).state == DELEGATED |
| aux_state | AuxStateEqual32( pdev_pre.aux, pdev_pre.num_aux, DELEGATED) |
15.3.17.4 Footprint
15.3.18 RMI_PDEV_GET_STATE command
Get state of a PDEV.
See also:
- Section 9
15.3.18.1 Interface
15.3.18.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000178 |
| pdev_ptr | X1 | 63:0 | Address | PA of the PDEV |
15.3.18.1.2 Context
The RMI_PDEV_GET_STATE command operates on the following context.
15.3.18.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| state | X1 | 7:0 | RmiPdevState | PDEV state |
The following unused bits of RMI_PDEV_GET_STATE output values MBZ: X1[63:8].
15.3.18.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_gran_state | pre: GranuleAt(pdev_ptr).state != PDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.18.2.1 Failure condition ordering
[da_supp] < [pdev_align, pdev_bound, pdev_gran_state]
15.3.18.3 Success conditions
| ID | Condition |
|---|---|
| state | Equal(state, pdev.state) |
15.3.18.4 Footprint
The RMI_PDEV_GET_STATE command does not have any footprint.
15.3.19 RMI_PDEV_IDE_RESET command
Reset the IDE link of a PDEV.
15.3.19.1 Interface
15.3.19.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000179 |
| pdev_ptr | X1 | 63:0 | Address | PA of the PDEV |
15.3.19.1.2 Context
The RMI_PDEV_IDE_RESET command operates on the following context.
15.3.19.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.19.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_gran_state | pre: GranuleAt(pdev_ptr).state != PDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_idepdev_state | pre: pdev.ide state !== IDE_FALSE PDEV_READY post: ResultEqual(result, RMI_ERROR_INPUT) pdev_state pre: pdev.state != PDEV_READY post: ResultEqual(result, RMI_ERROR_DEVICE) |
15.3.19.2.1 Failure condition ordering
[da_supp] < [pdev_align, pdev_bound, pdev_gran_state]
[pdev_gran_state] < [pdev_ide, pdev_state][pdev_state]
15.3.19.3 Success conditions
| ID | Condition |
|---|---|
| pdev_state | pdev.state == PDEV_IDE_RESETTING |
| comm_state | pdev.comm_state == DEV_COMM_PENDING |
15.3.19.4 Footprint
| ID | Value |
|---|---|
| state | pdev.state |
| comm_state | pdev.comm_state |
15.3.20 RMI_PDEV_NOTIFY command
Notify the RMM of an event related to a PDEV.
See also:
- Section 9
15.3.20.1 Interface
15.3.20.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400017A |
| pdev_ptr | X1 | 63:0 | Address | PA of the PDEV |
| ev | X2 | 7:0 | RmiPdevEvent | Event type |
The following unused bits of RMI_PDEV_NOTIFY input values SBZ: X2[63:8].
15.3.20.1.2 Context
The RMI_PDEV_NOTIFY command operates on the following context.
15.3.20.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.20.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_gran_state | pre: GranuleAt(pdev_ptr).state != PDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_state | pre: pdev.state != PDEV_READY post: ResultEqual(result, RMI_ERROR_DEVICE) |
| ev_valid | pre: !RmiPdevEventIsValid(ev) post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.20.2.1 Failure condition ordering
[da_supp] < [pdev_align, pdev_bound, pdev_gran_state]
[pdev_gran_state] < [pdev_state]
[pdev_state] < [ev_valid]
15.3.20.3 Success conditions
| ID | Condition |
|---|---|
| pdev_state | pdev.state == PDEV_COMMUNICATING |
| comm_state | pdev.comm_state == DEV_COMM_PENDING |
15.3.20.4 Footprint
| ID | Value |
|---|---|
| state | pdev.state |
| comm_state | pdev.comm_state |
15.3.21 RMI_PDEV_SET_PUBKEY command
Provide public key associated with a PDEV.
See also:
- Section 9
15.3.21.1 Interface
15.3.21.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400017B |
| pdev_ptr | X1 | 63:0 | Address | PA of the PDEV |
| key | X2 | 63:0 | Address | PA of the key |
| len | X3 | 63:0 | UInt64 | Length of the key in bytes |
| algo | X4 | 7:0 | RmiSignatureAlgorithm | Signature algorithm |
The following unused bits of RMI_PDEV_SET_PUBKEY input values SBZ: X4[63:8].
15.3.21.1.2 Context
The RMI_PDEV_SET_PUBKEY command operates on the following context.
15.3.21.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.21.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_gran_state | pre: GranuleAt(pdev_ptr).state != PDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| key_align | pre: !AddrIsGranuleAligned(key) post: ResultEqual(result, RMI_ERROR_INPUT) |
| key_bound | pre: !PaIsDelegable(key) post: ResultEqual(result, RMI_ERROR_INPUT) |
| key_pas | pre: !GranuleAccessPermitted(key, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| key_len_oflow | pre: len > RMM_GRANULE_SIZE post: ResultEqual(result, RMI_ERROR_INPUT) |
| key_invalid |
pre: Key is invalid, for example length is invalid for specified
signature algorithm.
post: ResultEqual(result, RMI_ERROR_INPUT)
|
| pdev_state | pre: pdev.state != PDEV_NEEDS_KEY post: ResultEqual(result, RMI_ERROR_DEVICE) |
15.3.21.2.1 Failure condition ordering
[da_supp] < [pdev_align, pdev_bound, pdev_gran_state, key_align,
key_bound, key_pas, key_len_oflow, key_invalid]
[pdev_gran_state] < [pdev_state]
15.3.21.3 Success conditions
| ID | Condition |
|---|---|
| state | pdev.state == PDEV_HAS_KEY |
| comm_state | pdev.comm_state == DEV_COMM_PENDING |
15.3.21.4 Footprint
| ID | Value |
|---|---|
| state | pdev.state |
| comm_state | pdev.comm_state |
15.3.22 RMI_PDEV_STOP command
Stop a PDEV.
See also:
- Section 9
15.3.22.1 Interface
15.3.22.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400017C |
| pdev_ptr | X1 | 63:0 | Address | PA of the PDEV |
15.3.22.1.2 Context
The RMI_PDEV_STOP command operates on the following context.
15.3.22.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.22.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_gran_state | pre: GranuleAt(pdev_ptr).state != PDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_state | pre: (pdev.state == PDEV_COMMUNICATING || pdev.state == PDEV_STOPPING || pdev.state == PDEV_STOPPED) post: ResultEqual(result, RMI_ERROR_DEVICE) |
| num_vdevs | pre: pdev.num_vdevs != 0 post: ResultEqual(result, RMI_ERROR_DEVICE) |
15.3.22.2.1 Failure condition ordering
[da_supp] < [pdev_align, pdev_bound, pdev_gran_state]
[pdev_gran_state] < [pdev_state, num_vdevs]
15.3.22.3 Success conditions
| ID | Condition |
|---|---|
| pdev_state | pdev.state == PDEV_STOPPING |
| comm_state | pdev.comm_state == DEV_COMM_PENDING |
15.3.22.4 Footprint
| ID | Value |
|---|---|
| state | pdev.state |
| comm_state | pdev.comm_state |
15.3.23 RMI_PSCI_COMPLETE command
Completes a pending PSCI command which was called with an MPIDR argument, by providing the corresponding REC.
15.3.23.1 Interface
15.3.23.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000164 |
| calling_rec_ptr | X1 | 63:0 | Address | PA of the calling REC |
| target_rec_ptr | X2 | 63:0 | Address | PA of the target REC |
| status | X3 | 63:0 | PsciReturnCode | Status of the PSCI request |
15.3.23.1.2 Context
The RMI_PSCI_COMPLETE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| calling_rec | RmmRec | RecAt(calling_rec_ptr) |
false | Calling REC |
| target_rec | RmmRec | RecAt(target_rec_ptr) |
false | Target REC |
15.3.23.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.23.2 Failure conditions
| ID | Condition |
|---|---|
| alias | pre: calling_rec_ptr == target_rec_ptr post: ResultEqual(result, RMI_ERROR_INPUT) |
| calling_align | pre: !AddrIsGranuleAligned(calling_rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| calling_bound | pre: !PaIsDelegable(calling_rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| calling_state | pre: GranuleAt(calling_rec_ptr).state != REC post: ResultEqual(result, RMI_ERROR_INPUT) |
| target_align | pre: !AddrIsGranuleAligned(target_rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| target_bound | pre: !PaIsDelegable(target_rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| target_state | pre: GranuleAt(target_rec_ptr).state != REC post: ResultEqual(result, RMI_ERROR_INPUT) |
| pending | pre: calling_rec.pending != REC_PENDING_PSCI post: ResultEqual(result, RMI_ERROR_INPUT) |
| owner | pre: target_rec.owner != calling_rec.owner post: ResultEqual(result, RMI_ERROR_INPUT) |
| target | pre: target_rec.mpidr != calling_rec.gprs[1] post: ResultEqual(result, RMI_ERROR_INPUT) |
| status | pre: !PsciReturnCodePermitted( calling_rec, target_rec, status) post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.23.2.1 Failure condition ordering
The RMI_PSCI_COMPLETE command does not have any failure condition orderings.
15.3.23.3 Success conditions
| ID | Condition |
|---|---|
| pending | calling_rec.pending == REC_PENDING_NONE |
| on_already | pre: (status == PSCI_SUCCESS && calling_rec.gprs[0] == FID_PSCI_CPU_ON && target_rec.flags.runnable == RUNNABLE) post: (calling_rec.gprs[0] == PsciReturnCodeEncode(PSCI_ALREADY_ON)) |
| on_success | pre: (status == PSCI_SUCCESS && calling_rec.gprs[0] == FID_PSCI_CPU_ON && target_rec.flags.runnable != RUNNABLE) post: (target_rec.gprs[0] == calling_rec.gprs[3] && target_rec.gprs[1] == Zeros(64) && target_rec.gprs[2] == Zeros(64) && target_rec.gprs[3] == Zeros(64) && target_rec.gprs[4] == Zeros(64) && target_rec.gprs[5] == Zeros(64) && target_rec.gprs[6] == Zeros(64) && target_rec.gprs[7] == Zeros(64) && target_rec.gprs[8] == Zeros(64) && target_rec.gprs[9] == Zeros(64) && target_rec.gprs[10] == Zeros(64) && target_rec.gprs[11] == Zeros(64) && target_rec.gprs[12] == Zeros(64) && target_rec.gprs[13] == Zeros(64) && target_rec.gprs[14] == Zeros(64) && target_rec.gprs[15] == Zeros(64) && target_rec.gprs[16] == Zeros(64) && target_rec.gprs[17] == Zeros(64) && target_rec.gprs[18] == Zeros(64) && target_rec.gprs[19] == Zeros(64) && target_rec.gprs[20] == Zeros(64) && target_rec.gprs[21] == Zeros(64) && target_rec.gprs[22] == Zeros(64) && target_rec.gprs[23] == Zeros(64) && target_rec.gprs[24] == Zeros(64) && target_rec.gprs[25] == Zeros(64) && target_rec.gprs[26] == Zeros(64) && target_rec.gprs[27] == Zeros(64) && target_rec.gprs[28] == Zeros(64) && target_rec.gprs[29] == Zeros(64) && target_rec.gprs[30] == Zeros(64) && target_rec.gprs[31] == Zeros(64) && target_rec.pc == calling_rec.gprs[2] && target_rec.flags.runnable == RUNNABLE && calling_rec.gprs[0] == PsciReturnCodeEncode(PSCI_SUCCESS)) |
| affinity_on | pre: (status == PSCI_SUCCESS && calling_rec.gprs[0] == FID_PSCI_AFFINITY_INFO && target_rec.flags.runnable == RUNNABLE) post: (calling_rec.gprs[0] == PsciReturnCodeEncode(PSCI_SUCCESS)) |
| affinity_off | pre: (status == PSCI_SUCCESS && calling_rec.gprs[0] == FID_PSCI_AFFINITY_INFO && target_rec.flags.runnable != RUNNABLE) post: (calling_rec.gprs[0] == PsciReturnCodeEncode(PSCI_OFF)) |
| status | pre: status != PSCI_SUCCESS post: (calling_rec.gprs[0] == PsciReturnCodeEncode(status)) |
| args |
(calling_rec.gprs[1] == Zeros(64)
&& calling_rec.gprs[2] == Zeros(64)
&& calling_rec.gprs[3] == Zeros(64))
|
15.3.23.4 Footprint
| ID | Value |
|---|---|
| target_flags | target_rec.flags |
| target_gprs | target_rec.gprs |
| target_pc | target_rec.pc |
| calling_pend | calling_rec.pending |
| calling_gprs | calling_rec.gprs |
15.3.24 RMI_REALM_ACTIVATE command
Activates a Realm.
See also:
- Section 2.1
15.3.24.1 Interface
15.3.24.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000157 |
| rd | X1 | 63:0 | Address | PA of the RD |
15.3.24.1.2 Context
The RMI_REALM_ACTIVATE command operates on the following context.
15.3.24.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.24.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| realm_state | pre: realm.state != REALM_NEW post: ResultEqual(result, RMI_ERROR_REALM) |
15.3.24.2.1 Failure condition ordering
[rd_bound, rd_state] < [realm_state]
15.3.24.3 Success conditions
| ID | Condition |
|---|---|
| realm_state | realm.state == REALM_ACTIVE |
15.3.24.4 Footprint
| ID | Value |
|---|---|
| realm_state | realm.state |
15.3.25 RMI_REALM_CREATE command
Creates a Realm.
15.3.25.1 Interface
15.3.25.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000158 |
| rd | X1 | 63:0 | Address | PA of the RD |
| params_ptr | X2 | 63:0 | Address | PA of Realm parameters |
15.3.25.1.2 Context
The RMI_REALM_CREATE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| params | RmiRealmParams | RmiRealmParamsAt( params_ptr) |
false | Realm parameters |
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| mec_members_pre | UInt64 | MecMembers(params.mecid) |
true | Number of Realms which are members of the Realm’s MEC |
| mec_state_pre | RmmMecState | MecState(params.mecid) |
true | MECID state |
15.3.25.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.25.2 Failure conditions
| ID | Condition |
|---|---|
| params_align | pre: !AddrIsGranuleAligned(params_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_bound | pre: !PaIsDelegable(params_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_pas | pre: !GranuleAccessPermitted(params_ptr, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_valid | pre: !RmiRealmParamsIsValid(params_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_supp | pre: !RealmParamsSupported(params) post: ResultEqual(result, RMI_ERROR_INPUT) |
| alias | pre: AddrInRange(rd, params.rtt_base, (params.rtt_num_start - 1) * RMM_GRANULE_SIZE) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != DELEGATED post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_align | pre: !AddrIsAligned(params.rtt_base, params.rtt_num_start * RMM_GRANULE_SIZE) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_num_level | pre: !RttConfigIsValid( params.s2sz, params.rtt_level_start, params.rtt_num_start) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_state | pre: !RttsStateEqual( params.rtt_base, params.rtt_num_start, DELEGATED) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vmid_valid | pre: (!VmidsAreValid(params.vmid, params.aux_vmid) || !VmidsAreFree(params.vmid, params.aux_vmid)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| mecid_bound | pre: UInt(params.mecid) > UInt(ImplFeatures().max_mecid) post: ResultEqual(result, RMI_ERROR_INPUT) |
| mecid_state | pre: MecState(params.mecid) == MEC_STATE_PRIVATE_ASSIGNED post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.25.2.1 Failure condition ordering
The RMI_REALM_CREATE command does not have any failure condition orderings.
15.3.25.3 Success conditions
| ID | Condition |
|---|---|
| rd_state | GranuleAt(rd).state == RD |
| realm_state | realm.state == REALM_NEW |
| rec_index | realm.rec_index == 0 |
| rtt_base | RealmRttBaseEqual( realm, params.rtt_base, params.aux_rtt_base) |
| rtt_state | RttsStateEqual( realm.rtt_base[0], realm.rtt_num_start, RTT) |
| rtte_p_states | RttsAllProtectedEntriesState( realm.rtt_base[0], realm.rtt_num_start, UNASSIGNED) |
| rtte_up_states | RttsAllUnprotectedEntriesState( realm.rtt_base[0], realm.rtt_num_start, UNASSIGNED_NS) |
| rtte_ripas | RttsAllProtectedEntriesRipas( realm.rtt_base[0], realm.rtt_num_start, EMPTY) |
| lpa2 | Equal(realm.feat_lpa2, params.flags0.lpa2) |
| ipa_width | realm.ipa_width == params.s2sz |
| hash_algo | Equal(realm.hash_algo, params.hash_algo) |
| rim | realm.measurements[0] == RimInit( realm.hash_algo, params) |
| rem |
(realm.measurements[1] == Zeros(RMM_REALM_MEASUREMENT_WIDTH)
&& realm.measurements[2] == Zeros(RMM_REALM_MEASUREMENT_WIDTH)
&& realm.measurements[3] == Zeros(RMM_REALM_MEASUREMENT_WIDTH)
&& realm.measurements[4] == Zeros(RMM_REALM_MEASUREMENT_WIDTH))
|
| rtt_level | realm.rtt_level_start == params.rtt_level_start |
| rtt_num | realm.rtt_num_start == params.rtt_num_start |
| vmid | RealmVmidEqual( realm, params.vmid, params.aux_vmid) |
| rpv | realm.rpv == params.rpv |
| da | Equal(realm.feat_da, params.flags0.da) |
| rtt_tree_pp | Equal(realm.rtt_tree_pp, params.flags1.rtt_tree_pp) |
| num_aux_planes | realm.num_aux_planes == params.num_aux_planes |
| lfa_policy | Equal(realm.lfa_policy, params.flags0.lfa_policy) |
| mecid | realm.mecid == params.mecid |
| mec_policy | realm.mec_policy == MecPolicy(realm.mecid) |
| mecid_private | pre: mec_state_pre == MEC_STATE_PRIVATE_UNASSIGNED post: MecState(params.mecid) == MEC_STATE_PRIVATE_ASSIGNED |
| mec_members | pre: mec_state_pre == MEC_STATE_SHARED post: MecMembers(params.mecid) == mec_members_pre + 1 |
| num_recs | realm.num_recs == 0 |
| num_vdevs | realm.num_vdevs == 0 |
15.3.25.4 RMI_REALM_CREATE initialization of RIM
On successful execution of RMI_REALM_CREATE, the initial RIM value of the target Realm is calculated by the RMM as follows:
Allocate a zero-filled RmiRealmParams data structure to hold the measured Realm parameters.
Copy the following attributes from the Host-provided RmiRealmParams data structure into the measured Realm parameters data structure:
- flags0
- s2sz
- sve_vl
- num_bps
- num_wps
- pmu_num_ctrs
- hash_algo
- Using the RHA of the target Realm, compute the hash of the measured Realm parameters data structure. Set the RIM of the target Realm to this value, zero filling upper bytes if the RHA output is smaller than the size of the RIM.
15.3.25.5 Footprint
| ID | Value |
|---|---|
| rd_state | GranuleAt(rd).state |
| rtt_state | RttsGranuleState( realm.rtt_base[0], realm.rtt_num_start) |
15.3.26 RMI_REALM_DESTROY command
Destroys a Realm.
15.3.26.1 Interface
15.3.26.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000159 |
| rd | X1 | 63:0 | Address | PA of the RD |
15.3.26.1.2 Context
The RMI_REALM_DESTROY command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm_pre | RmmRealm | RealmAt(rd) |
true | Realm |
| mec_members_pre | UInt64 | MecMembers(realm_pre.mecid) |
true | Number of Realms which are members of the Realm’s MEC |
15.3.26.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.26.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| realm_live | pre: RealmIsLive(rd) post: ResultEqual(result, RMI_ERROR_REALM) |
15.3.26.2.1 Failure condition ordering
[rd_bound, rd_state] < [realm_live]
15.3.26.3 Success conditions
| ID | Condition |
|---|---|
| rtt_state | RttsStateEqual( realm_pre.rtt_base[0], realm_pre.rtt_num_start, DELEGATED) |
| rd_state | GranuleAt(rd).state == DELEGATED |
| vmid | VmidsAreFree(realm_pre.vmid) |
| mecid_private | pre: realm_pre.mec_policy == MEC_POLICY_PRIVATE post: MecState(realm_pre.mecid) == MEC_STATE_PRIVATE_UNASSIGNED |
| mec_members | pre: realm_pre.mec_policy == MEC_POLICY_SHARED post: MecMembers(realm_pre.mecid) == mec_members_pre - 1 |
15.3.26.4 Footprint
| ID | Value |
|---|---|
| rd_state | GranuleAt(rd).state |
| rtt_state | RttsGranuleState( realm_pre.rtt_base[0], realm_pre.rtt_num_start) |
15.3.27 RMI_REC_AUX_COUNT command
Get number of auxiliary Granules required for a REC.
15.3.27.1 Interface
15.3.27.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000167 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
15.3.27.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| aux_count | X1 | 63:0 | UInt64 | Number of auxiliary Granules required for a REC |
15.3.27.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.27.2.1 Failure condition ordering
The RMI_REC_AUX_COUNT command does not have any failure condition orderings.
15.3.27.3 Success conditions
| ID | Condition |
|---|---|
| aux_count | aux_count == RecAuxCount(rd) |
15.3.27.4 Footprint
The RMI_REC_AUX_COUNT command does not have any footprint.
15.3.28 RMI_REC_CREATE command
Creates a REC.
15.3.28.1 Interface
15.3.28.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400015A |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| rec_ptr | X2 | 63:0 | Address | PA of the target REC |
| params_ptr | X3 | 63:0 | Address | PA of REC parameters |
15.3.28.1.2 Context
The RMI_REC_CREATE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm_pre | RmmRealm | RealmAt(rd) |
true | Realm |
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| params | RmiRecParams | RmiRecParamsAt(params_ptr) |
false | REC parameters |
| rec | RmmRec | RecAt(rec_ptr) |
false | REC |
15.3.28.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.28.2 Failure conditions
| ID | Condition |
|---|---|
| params_align | pre: !AddrIsGranuleAligned(params_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_bound | pre: !PaIsDelegable(params_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_pas | pre: !GranuleAccessPermitted(params_ptr, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_align | pre: !AddrIsGranuleAligned(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_bound | pre: !PaIsDelegable(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_state | pre: GranuleAt(rec_ptr).state != DELEGATED post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| realm_state | pre: realm_pre.state != REALM_NEW post: ResultEqual(result, RMI_ERROR_REALM) |
| num_recs | pre: realm_pre.num_recs == (2 ^ ImplFeatures().max_recs_order) - 1 post: ResultEqual(result, RMI_ERROR_REALM) |
| mpidr_index | pre: RecIndex(params.mpidr) != realm_pre.rec_index post: ResultEqual(result, RMI_ERROR_INPUT) |
| num_aux | pre: params.num_aux != RecAuxCount(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| aux_align | pre: !AuxAligned16(params.aux, params.num_aux) post: ResultEqual(result, RMI_ERROR_INPUT) |
| aux_alias | pre: AuxAlias16(rec_ptr, params.aux, params.num_aux) post: ResultEqual(result, RMI_ERROR_INPUT) |
| aux_state | pre: !AuxStateEqual16( params.aux, params.num_aux, DELEGATED) post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.28.2.1 Failure condition ordering
[rd_bound, rd_state] < [realm_state, num_recs]
15.3.28.3 Success conditions
| ID | Condition |
|---|---|
| rec_index | realm.rec_index == realm_pre.rec_index + 1 |
| rec_gran_state | GranuleAt(rec_ptr).state == REC |
| rec_owner | rec.owner == rd |
| rec_attest | rec.attest_state == NO_ATTEST_IN_PROGRESS |
| rec_mpidr | MpidrEqual(rec.mpidr, params.mpidr) |
| rec_state | rec.state == REC_READY |
| runnable | pre: params.flags.runnable == RMI_RUNNABLE post: rec.flags.runnable == RUNNABLE |
| not_runnable | pre: params.flags.runnable == RMI_NOT_RUNNABLE post: rec.flags.runnable == NOT_RUNNABLE |
| rec_gprs |
(rec.gprs[0] == params.gprs[0]
&& rec.gprs[1] == params.gprs[1]
&& rec.gprs[2] == params.gprs[2]
&& rec.gprs[3] == params.gprs[3]
&& rec.gprs[4] == params.gprs[4]
&& rec.gprs[5] == params.gprs[5]
&& rec.gprs[6] == params.gprs[6]
&& rec.gprs[7] == params.gprs[7]
&& rec.gprs[8] == Zeros(64)
&& rec.gprs[9] == Zeros(64)
&& rec.gprs[10] == Zeros(64)
&& rec.gprs[11] == Zeros(64)
&& rec.gprs[12] == Zeros(64)
&& rec.gprs[13] == Zeros(64)
&& rec.gprs[14] == Zeros(64)
&& rec.gprs[15] == Zeros(64)
&& rec.gprs[16] == Zeros(64)
&& rec.gprs[17] == Zeros(64)
&& rec.gprs[18] == Zeros(64)
&& rec.gprs[19] == Zeros(64)
&& rec.gprs[20] == Zeros(64)
&& rec.gprs[21] == Zeros(64)
&& rec.gprs[22] == Zeros(64)
&& rec.gprs[23] == Zeros(64)
&& rec.gprs[24] == Zeros(64)
&& rec.gprs[25] == Zeros(64)
&& rec.gprs[26] == Zeros(64)
&& rec.gprs[27] == Zeros(64)
&& rec.gprs[28] == Zeros(64)
&& rec.gprs[29] == Zeros(64)
&& rec.gprs[30] == Zeros(64)
&& rec.gprs[31] == Zeros(64))
|
| rec_pc | rec.pc == params.pc |
| rim | pre: params.flags.runnable == RMI_RUNNABLE post: realm.measurements[0] == RimExtendRec( realm_pre, params) |
| rec_aux | AuxEqual16( rec.aux, params.aux, RecAuxCount(rd)) |
| rec_aux_state | AuxStateEqual16( rec.aux, RecAuxCount(rd), REC_AUX) |
| ripas_addr | rec.ripas_addr == Zeros(ADDRESS_WIDTH) |
| ripas_top | rec.ripas_top == Zeros(ADDRESS_WIDTH) |
| pending | rec.pending == REC_PENDING_NONE |
| num_recs | realm.num_recs == realm_pre.num_recs + 1 |
| gic_owner | rec.gic_owner == 0 |
15.3.28.4 RMI_REC_CREATE extension of RIM
On successful execution of RMI_REC_CREATE, if the new REC is runnable then the new RIM value of the target Realm is calculated by the RMM as follows:
Allocate a zero-filled RmiRecParams data structure to hold the measured REC parameters.
Copy the following attributes from the Host-provided RmiRecParams data structure into the measured REC parameters data structure:
- gprs
- pc
- flags
Using the RHA of the target Realm, compute the hash of the measured REC parameters data structure.
Allocate an RmmMeasurementDescriptorRec data structure.
Populate the measurement descriptor:
- Set the desc_type field to the descriptor type.
- Set the len field to the descriptor length.
- Set the rim field to the current RIM value of the target Realm.
- Set the content field to the hash of the measured REC parameters.
- Using the RHA of the target Realm, compute the hash of the measurement descriptor. Set the RIM of the target Realm to this value, zero filling upper bytes if the RHA output is smaller than the size of the RIM.
15.3.28.5 Footprint
| ID | Value |
|---|---|
| rec_index | realm.rec_index |
| rec_state | GranuleAt(rec).state |
| rec_aux_state | AuxStates(rec.aux, RecAuxCount(rd)) |
| rim | realm.measurements[0] |
| num_recs |
realm.num_recs
|
15.3.29 RMI_REC_DESTROY command
Destroys a REC.
15.3.29.1 Interface
15.3.29.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400015B |
| rec_ptr | X1 | 63:0 | Address | PA of the target REC |
15.3.29.1.2 Context
The RMI_REC_DESTROY command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| rd_pre | Address | RecAt(rec_ptr).owner |
true | RD address |
| realm_pre | RmmRealm | RealmAt(rd_pre) |
true | Realm |
| realm | RmmRealm | RealmAt(rd_pre) |
false | Realm |
| rec_pre | RmmRec | RecAt(rec_ptr) |
true | REC |
| rec | RmmRec | RecAt(rec_ptr) |
false | REC |
15.3.29.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.29.2 Failure conditions
| ID | Condition |
|---|---|
| rec_align | pre: !AddrIsGranuleAligned(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_bound | pre: !PaIsDelegable(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_gran_state | pre: GranuleAt(rec_ptr).state != REC post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_state | pre: rec.state == REC_RUNNING post: ResultEqual(result, RMI_ERROR_REC) |
15.3.29.2.1 Failure condition ordering
[rec_bound, rec_gran_state] < [rec_state]
15.3.29.3 Success conditions
| ID | Condition |
|---|---|
| rec_gran_state | GranuleAt(rec_ptr).state == DELEGATED |
| rec_aux_state | AuxStateEqual16( rec_pre.aux, RecAuxCount(rd_pre), DELEGATED) |
| num_recs | realm.num_recs == realm_pre.num_recs - 1 |
15.3.29.4 Footprint
| ID | Value |
|---|---|
| rec_state | GranuleAt(rec_ptr).state |
| rec_aux_state | AuxStates(rec_pre.aux, RecAuxCount(rd_pre)) |
| num_recs |
realm.num_recs
|
15.3.30 RMI_REC_ENTER command
Enter a REC.
15.3.30.1 Interface
15.3.30.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400015C |
| rec_ptr | X1 | 63:0 | Address | PA of the target REC |
| run_ptr | X2 | 63:0 | Address | PA of RecRun object |
The number of GICv3 List Register values which can be provided by the Host in RmiRecEnter, and which are returned in RmiRecExit, is reported by the RMI_FEATURES command.
See also:
- Section 3.13
15.3.30.1.2 Context
The RMI_REC_ENTER command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| run | RmiRecRun | RmiRecRunAt(run_ptr) |
false | RecRun object |
| rec | RmmRec | RecAt(rec_ptr) |
false | REC |
| realm | RmmRealm | RealmAt(rec.owner) |
false | Realm |
15.3.30.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.30.2 Failure conditions
| ID | Condition |
|---|---|
| run_align | pre: !AddrIsGranuleAligned(run_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| run_bound | pre: !PaIsDelegable(run_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| run_pas | pre: !GranuleAccessPermitted(run_ptr, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_align | pre: !AddrIsGranuleAligned(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_bound | pre: !PaIsDelegable(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_gran_state | pre: GranuleAt(rec_ptr).state != REC post: ResultEqual(result, RMI_ERROR_INPUT) |
| realm_new | pre: realm.state == REALM_NEW post: ResultEqual(result, RMI_ERROR_REALM, 0) |
| system_off | pre: realm.state == REALM_SYSTEM_OFF post: ResultEqual(result, RMI_ERROR_REALM, 1) |
| rec_state | pre: rec.state == REC_RUNNING post: ResultEqual(result, RMI_ERROR_REC) |
| rec_runnable | pre: rec.flags.runnable == NOT_RUNNABLE post: ResultEqual(result, RMI_ERROR_REC) |
| rec_mmio | pre: (run.enter.flags.emul_mmio == RMI_EMULATED_MMIO && rec.emulatable_abort != EMULATABLE_ABORT) post: ResultEqual(result, RMI_ERROR_REC) |
| rec_gicv3 | pre: !Gicv3ConfigIsValid( run.enter.gicv3_hcr, run.enter.gicv3_lrs) post: ResultEqual(result, RMI_ERROR_REC) |
| rec_pending | pre: rec.pending != REC_PENDING_NONE post: ResultEqual(result, RMI_ERROR_REC) |
15.3.30.2.1 Failure condition ordering
[rec_align, rec_bound, rec_gran_state, run_pas, run_bound, run_align]
< [rec_state, rec_runnable, rec_mmio, realm_new, system_off,
rec_gicv3, rec_pending]
15.3.30.3 Success conditions
| ID | Condition |
|---|---|
| rec_exit | run.exit contains Realm exit syndrome information. |
| rec_emul_abt | rec.emulatable_abort is updated. |
15.3.30.4 Footprint
| ID | Value |
|---|---|
| emul_abt | rec.emulatable_abort |
15.3.31 RMI_RTT_AUX_CREATE command
Creates an auxiliary RTT.
15.3.31.1 Interface
15.3.31.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400017D |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| rtt | X2 | 63:0 | Address | PA of the target RTT |
| ipa | X3 | 63:0 | Address | Base of the IPA range described by the RTT |
| level | X4 | 63:0 | Int64 | RTT level |
| index | X5 | 63:0 | UInt64 | RTT tree index |
15.3.31.1.2 Context
The RMI_RTT_AUX_CREATE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, level - 1, index) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| unfold | RmmRttEntry | RttWalk( rd, ipa, level - 1, index).rtte |
true | RTTE before command execution |
15.3.31.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.31.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| level_bound | pre: (!RttLevelIsValid(rd, level) || RttLevelIsStarting(rd, level)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsRttLevelAligned(ipa, level - 1) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: UInt(ipa) >= (2 ^ realm.ipa_width) post: ResultEqual(result, RMI_ERROR_INPUT) |
| index_bound | pre: (realm.rtt_tree_pp == FEATURE_FALSE || index == RMM_RTT_TREE_PRIMARY || index > realm.num_aux_planes) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_align | pre: !AddrIsGranuleAligned(rtt) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_bound | pre: !PaIsDelegable(rtt) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_state | pre: GranuleAt(rtt).state != DELEGATED post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_bound2 | pre: ((realm.feat_lpa2 == FEATURE_FALSE) && (UInt(rtt) >= 2^48)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_walk | pre: walk.level < level - 1 post: ResultEqual(result, RMI_ERROR_RTTRMI_ERROR_RTT_AUX, walk.level) |
| rtte_state | pre: walk.rtte.state == TABLE post: ResultEqual(result, RMI_ERROR_RTTRMI_ERROR_RTT_AUX, walk.level) |
15.3.31.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state]
[level_bound, ipa_bound] < [rtt_walk, rtte_state]
15.3.31.3 Success conditions
| ID | Condition |
|---|---|
| rtt_state | GranuleAt(rtt).state == RTT |
| rtte_state | walk.rtte.state == TABLE |
| rtte_addr | walk.rtte.addr == rtt |
| rtte_c_ripas | pre: AddrIsProtected(ipa, realm) post: RttAllEntriesRipas(RttAt(rtt), unfold.ripas) |
| rtte_c_state | RttAllEntriesState(RttAt(rtt), unfold.state) |
| rtte_c_addr | pre: (unfold.state != UNASSIGNED && unfold.state != UNASSIGNED_NS) post: RttAllEntriesContiguous(RttAt(rtt), unfold.addr, level) |
15.3.31.4 Footprint
| ID | Value |
|---|---|
| rtt_state | GranuleAt(rtt).state |
| rtte | RttEntry(walk.rtt_addr, entry_idx) |
15.3.32 RMI_RTT_AUX_DESTROY command
Destroys an auxiliary RTT.
15.3.32.1 Interface
15.3.32.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400017E |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | Base of the IPA range described by the RTT |
| level | X3 | 63:0 | Int64 | RTT level |
| index | X4 | 63:0 | UInt64 | RTT tree index |
15.3.32.1.2 Context
The RMI_RTT_AUX_DESTROY command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, level - 1, index) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| walk_top | Address | RttSkipNonLiveEntries( RttAt(walk.rtt_addr), walk.level, ipa) |
false | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
15.3.32.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| rtt | X1 | 63:0 | Address | PA of the RTT which was destroyed |
| top | X2 | 63:0 | Address | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
15.3.32.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| level_bound | pre: (!RttLevelIsValid(rd, level) || RttLevelIsStarting(rd, level)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsRttLevelAligned(ipa, level - 1) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: UInt(ipa) >= (2 ^ realm.ipa_width) post: ResultEqual(result, RMI_ERROR_INPUT) |
| index_bound | pre: (realm.rtt_tree_pp == FEATURE_FALSE || index == RMM_RTT_TREE_PRIMARY || index > realm.num_aux_planes) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_walk | pre: walk.level < level - 1 post: (ResultEqual(result, RMI_ERROR_RTTRMI_ERROR_RTT_AUX, walk.level) && (top == walk_top)) |
| rtte_state | pre: walk.rtte.state != TABLE post: (ResultEqual(result, RMI_ERROR_RTTRMI_ERROR_RTT_AUX, walk.level) && (top == walk_top)) |
| rtt_live | pre: RttIsLive(RttAt(walk.rtte.addr)) post: (ResultEqual(result, RMI_ERROR_RTTRMI_ERROR_RTT_AUX, level) && (top == ipa)) |
15.3.32.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state, rtt_live]
[level_bound, ipa_bound] < [rtt_walk, rtte_state]
15.3.32.3 Success conditions
| ID | Condition |
|---|---|
| rtte_state | walk.rtte.state == AUX_DESTROYED |
| ripas | walk.rtte.ripas == DESTROYED |
| rtt_state | GranuleAt(walk.rtte.addr).state == DELEGATED |
| rtt | rtt == walk.rtte.addr |
| top | top == walk_top |
15.3.32.4 Footprint
| ID | Value |
|---|---|
| rtt_state | GranuleAt(walk.rtte.addr).state |
| rtte | RttEntry(walk.rtt_addr, entry_idx) |
15.3.33 RMI_RTT_AUX_FOLD command
Destroys a homogeneous auxiliary RTT.
15.3.33.1 Interface
15.3.33.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400017F |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | Base of the IPA range described by the RTT |
| level | X3 | 63:0 | Int64 | RTT level |
| index | X4 | 63:0 | UInt64 | RTT tree index |
15.3.33.1.2 Context
The RMI_RTT_AUX_FOLD command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, level - 1, index) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| fold_pre | RmmRttEntry | RttFold( RttAt(walk.rtte.addr)) |
true | Result of folding RTT |
15.3.33.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| rtt | X1 | 63:0 | Address | PA of the RTT which was destroyed |
15.3.33.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| level_bound | pre: (!RttLevelIsValid(rd, level) || RttLevelIsStarting(rd, level)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsRttLevelAligned(ipa, level - 1) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: UInt(ipa) >= (2 ^ realm.ipa_width) post: ResultEqual(result, RMI_ERROR_INPUT) |
| index_bound | pre: (realm.rtt_tree_pp == FEATURE_FALSE || index == RMM_RTT_TREE_PRIMARY || index > realm.num_aux_planes) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_walk | pre: walk.level < level - 1 post: ResultEqual(result, RMI_ERROR_RTTRMI_ERROR_RTT_AUX, walk.level) |
| rtte_state | pre: walk.rtte.state != TABLE post: ResultEqual(result, RMI_ERROR_RTTRMI_ERROR_RTT_AUX, walk.level) |
| rtt_homo | pre: !RttIsHomogeneous(RttAt(walk.rtte.addr)) post: ResultEqual(result, RMI_ERROR_RTTRMI_ERROR_RTT_AUX, level) |
15.3.33.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state, rtt_homo]
[level_bound, ipa_bound] < [rtt_walk, rtte_state]
15.3.33.3 Success conditions
| ID | Condition |
|---|---|
| rtte_state | walk.rtte.state == fold_pre.state |
| rtte_addr | pre: (fold_pre.state != UNASSIGNED && fold_pre.state != UNASSIGNED_NS) post: walk.rtte.addr == fold_pre.addr |
| rtte_attr | pre: (fold_pre.state == ASSIGNED || fold_pre.state == ASSIGNED_NS) post: (walk.rtte.MemAttr == fold_pre.MemAttr && walk.rtte.S2APs2ap_base == fold_pre.S2APs2ap_base && walk.rtte.s2ap_overlay == fold_pre.s2ap_overlay) |
| rtte_ripas | pre: AddrIsProtected(ipa, realm) post: walk.rtte.ripas == fold_pre.ripas |
| rtt_state | GranuleAt(walk.rtte.addr).state == DELEGATED |
| rtt | rtt == walk.rtte.addr |
15.3.33.4 Footprint
| ID | Value |
|---|---|
| rtt_state | GranuleAt(walk.rtte.addr).state |
| rtte | RttEntry(walk.rtt_addr, entry_idx) |
15.3.34 RMI_RTT_AUX_MAP_PROTECTED command
Creates a mapping from an Protected IPA in an auxiliary RTT.
15.3.34.1 Interface
15.3.34.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000180 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | IPA in the target Realm |
| index | X3 | 63:0 | UInt64 | RTT tree index |
15.3.34.1.2 Context
The RMI_RTT_AUX_MAP_PROTECTED command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk_pri | RmmRttWalkResult | RttWalk( rd, ipa, RMM_RTT_PAGE_LEVEL, RMM_RTT_TREE_PRIMARY) |
false | Primary RTT walk result |
| walk_aux | RmmRttWalkResult | RttWalk( rd, ipa, RMM_RTT_PAGE_LEVEL, index) |
false | Auxiliary RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk_aux.level) |
false | RTTE index |
15.3.34.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| fail_index | X1 | 63:0 | UInt64 | Index of RTT tree whose contents caused command to fail with RMI_ERROR_RTT |
| level_pri | X2 | 63:0 | Int64 | Level of RTTE reached by walk of primary RTT tree |
| state | X3 | 7:0 | RmiRttEntryState | State of RTT entry whose contents caused command to fail with RMI_ERROR_RTT |
| ripas | X4 | 7:0 | RmiRipas | RIPAS of RTT entry which caused command to fail with RMI_ERROR_RTT |
The following unused bits of RMI_RTT_AUX_MAP_PROTECTED output values MBZ: X3[63:8], X4[63:8].
15.3.34.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsGranuleAligned(ipa) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: !AddrIsProtected(ipa, realm) post: ResultEqual(result, RMI_ERROR_INPUT) |
| index_bound | pre: (realm.rtt_tree_pp == FEATURE_FALSE || index == RMM_RTT_TREE_PRIMARY || index > realm.num_aux_planes) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pri_state | pre: walk_pri.rtte.state != ASSIGNED post: (ResultEqual(result, RMI_ERROR_RTT, walk_pri.level) && (fail_index == RMM_RTT_TREE_PRIMARY) && (level_pri == walk_pri.level) && (state == RttEntryStateToRmi( walk_pri.rtte.state)) && (ripas == RipasToRmi( walk_pri.rtte.ripas))) |
| aux_destroyed | pre: walk_aux.rtte.state == AUX_DESTROYED post: (ResultEqual(result, RMI_ERROR_RTT_AUX, walk_aux.level) && (fail_index == index) && (level_pri == walk_pri.level) && (state == RttEntryStateToRmi( walk_aux.rtte.state)) && (ripas == RipasToRmi( walk_pri.rtte.ripas))) |
| level | pre: walk_aux.level < walk_pri.level post: (ResultEqual(result, RMI_ERROR_RTT_AUX, walk_aux.level) && (fail_index == index) && (level_pri == walk_pri.level) && (state == RttEntryStateToRmi( walk_aux.rtte.state)) && (ripas == RipasToRmi( walk_pri.rtte.ripas))) |
15.3.34.2.1 Failure condition ordering
[rd_bound, rd_state] < [pri_state, aux_destroyed, level]
[ipa_bound, index_bound] < [pri_state, aux_destroyed, level]
15.3.34.3 Success conditions
| ID | Condition |
|---|---|
| rtte_state | walk_aux.rtte.state == ASSIGNED |
| rtte_attr | walk_aux.rtte.MemAttr == walk_pri.rtte.MemAttr |
| rtte_addr |
walk_aux.rtte.addr ==
walk_pri.rtte.addr + (entry_idx * RttLevelSize(walk_aux.level))
|
15.3.34.4 Footprint
| ID | Value |
|---|---|
| rtte | RttEntry(walk_aux.rtt_addr, entry_idx) |
15.3.35 RMI_RTT_AUX_MAP_UNPROTECTED command
Creates a mapping from an Unprotected IPA in an auxiliary RTT.
15.3.35.1 Interface
15.3.35.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000181 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | IPA in the target Realm |
| index | X3 | 63:0 | UInt64 | RTT tree index |
15.3.35.1.2 Context
The RMI_RTT_AUX_MAP_UNPROTECTED command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk_pri | RmmRttWalkResult | RttWalk( rd, ipa, RMM_RTT_PAGE_LEVEL, RMM_RTT_TREE_PRIMARY) |
false | Primary RTT walk result |
| walk_aux | RmmRttWalkResult | RttWalk( rd, ipa, RMM_RTT_PAGE_LEVEL, index) |
false | Auxiliary RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk_aux.level) |
false | RTTE index |
15.3.35.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| fail_index | X1 | 63:0 | UInt64 | Index of RTT tree whose contents caused command to fail with RMI_ERROR_RTT |
| level_pri | X2 | 63:0 | Int64 | Level of RTTE reached by walk of primary RTT tree |
| state | X3 | 7:0 | RmiRttEntryState | State of RTT entry whose contents caused command to fail with RMI_ERROR_RTT |
The following unused bits of RMI_RTT_AUX_MAP_UNPROTECTED output values MBZ: X3[63:8].
15.3.35.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsGranuleAligned(ipa) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound |
pre: (UInt(ipa) >= (2 ^ realm.ipa_width)
|| AddrIsProtected(ipa, realm))
post: ResultEqual(result, RMI_ERROR_INPUT)
|
| index_bound | pre: (realm.rtt_tree_pp == FEATURE_FALSE || index == RMM_RTT_TREE_PRIMARY || index > realm.num_aux_planes) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pri_state | pre: walk_pri.rtte.state != ASSIGNED_NS post: (ResultEqual(result, RMI_ERROR_RTT, walk_pri.level) && (fail_index == RMM_RTT_TREE_PRIMARY) && (state == RttEntryStateToRmi( walk_pri.rtte.state)) && (level_pri == walk_pri.level)) |
| level | pre: walk_aux.level < walk_pri.level post: (ResultEqual(result, RMI_ERROR_RTT_AUX, walk_aux.level) && (fail_index == index) && (level_pri == walk_pri.level) && (state == RttEntryStateToRmi( walk_aux.rtte.state))) |
15.3.35.2.1 Failure condition ordering
[rd_bound, rd_state] < [pri_state, level]
[ipa_bound, index_bound] < [pri_state, level]
15.3.35.3 Success conditions
| ID | Condition |
|---|---|
| rtte_state | walk_aux.rtte.state == ASSIGNED_NS |
| rtte_attr |
(walk_aux.rtte.MemAttr == walk_pri.rtte.MemAttr
&& walk_aux.rtte.S2APs2ap_base == walk_pri.rtte.S2APs2ap_base
&& walk_aux.rtte.s2ap_overlay == walk_pri.rtte.s2ap_overlay)
|
| rtte_addr |
walk_aux.rtte.addr ==
walk_pri.rtte.addr + (entry_idx * RttLevelSize(walk_aux.level))
|
15.3.35.4 Footprint
| ID | Value |
|---|---|
| rtte | RttEntry(walk_aux.rtt_addr, entry_idx) |
15.3.36 RMI_RTT_AUX_UNMAP_PROTECTED command
Removes a mapping from an Protected IPA in an auxiliary RTT.
15.3.36.1 Interface
15.3.36.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000183 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | IPA in the target Realm |
| index | X3 | 63:0 | UInt64 | RTT tree index |
15.3.36.1.2 Context
The RMI_RTT_AUX_UNMAP_PROTECTED command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, RMM_RTT_PAGE_LEVEL, index) |
false | Auxiliary RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| walk_top | Address | RttSkipNonLiveEntries( RttAt(walk.rtt_addr), walk.level, ipa) |
false | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
15.3.36.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| top | X1 | 63:0 | Address | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
| level | X2 | 63:0 | Int64 | RTT level reached by the RTT walk |
15.3.36.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsGranuleAligned(ipa) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: !AddrIsProtected(ipa, realm) post: ResultEqual(result, RMI_ERROR_INPUT) |
| index_bound | pre: (realm.rtt_tree_pp == FEATURE_FALSE || index == RMM_RTT_TREE_PRIMARY || index > realm.num_aux_planes) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtte_state | pre: walk.rtte.state != ASSIGNED post: (ResultEqual(result, RMI_ERROR_RTTRMI_ERROR_RTT_AUX, walk.level) && (top == walk_top)) |
15.3.36.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtte_state]
[ipa_bound, index_bound] < [rtte_state]
15.3.36.3 Success conditions
| ID | Condition |
|---|---|
| rtte_state | walk.rtte.state == UNASSIGNED |
| top | top == walk_top |
| level | level == walk.level |
15.3.36.4 Footprint
| ID | Value |
|---|---|
| rtte | RttEntry(walk.rtt_addr, entry_idx) |
15.3.37 RMI_RTT_AUX_UNMAP_UNPROTECTED command
Removes a mapping from an Unprotected IPA in an auxiliary RTT.
15.3.37.1 Interface
15.3.37.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000184 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | IPA in the target Realm |
| index | X3 | 63:0 | UInt64 | RTT tree index |
15.3.37.1.2 Context
The RMI_RTT_AUX_UNMAP_UNPROTECTED command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, RMM_RTT_PAGE_LEVEL, index) |
false | Auxiliary RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| walk_top | Address | RttSkipNonLiveEntries( RttAt(walk.rtt_addr), walk.level, ipa) |
false | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
15.3.37.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| top | X1 | 63:0 | Address | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
| level | X2 | 63:0 | Int64 | RTT level reached by the RTT walk |
15.3.37.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsGranuleAligned(ipa) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound |
pre: (UInt(ipa) >= (2 ^ realm.ipa_width)
|| AddrIsProtected(ipa, realm))
post: ResultEqual(result, RMI_ERROR_INPUT)
|
| index_bound | pre: (realm.rtt_tree_pp == FEATURE_FALSE || index == RMM_RTT_TREE_PRIMARY || index > realm.num_aux_planes) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtte_state | pre: walk.rtte.state != ASSIGNED_NS post: (ResultEqual(result, RMI_ERROR_RTTRMI_ERROR_RTT_AUX, walk.level) && (top == walk_top)) |
15.3.37.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtte_state]
[ipa_bound, index_bound] < [rtte_state]
15.3.37.3 Success conditions
| ID | Condition |
|---|---|
| rtte_state | walk.rtte.state == UNASSIGNED_NS |
| top | top == walk_top |
| level | level == walk.level |
15.3.37.4 Footprint
| ID | Value |
|---|---|
| rtte | RttEntry(walk.rtt_addr, entry_idx) |
15.3.38 RMI_RTT_CREATE command
Creates a primary RTT.
15.3.38.1 Interface
15.3.38.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400015D |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| rtt | X2 | 63:0 | Address | PA of the target RTT |
| ipa | X3 | 63:0 | Address | Base of the IPA range described by the RTT |
| level | X4 | 63:0 | Int64 | RTT level |
15.3.38.1.2 Context
The RMI_RTT_CREATE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, level - 1, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| unfoldwalk_pre | RmmRttWalkResult | RttWalk( rd, ipa, level - 1, RMM_RTT_TREE_PRIMARY) |
true | RTT walk result before command execution |
| rtte_pre | RmmRttEntry | RttWalk( rd, ipa, level - 1, RMM_RTT_TREE_PRIMARY)walk_pre.rtte |
true | RTTE before command execution |
15.3.38.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.38.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| level_bound | pre: (!RttLevelIsValid(rd, level) || RttLevelIsStarting(rd, level)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsRttLevelAligned(ipa, level - 1) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: UInt(ipa) >= (2 ^ realm.ipa_width) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_align | pre: !AddrIsGranuleAligned(rtt) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_bound | pre: !PaIsDelegable(rtt) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_state | pre: GranuleAt(rtt).state != DELEGATED post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_bound2 | pre: ((realm.feat_lpa2 == FEATURE_FALSE) && (UInt(rtt) >= 2^48)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_walk | pre: walk.level < level - 1 post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
| rtte_state | pre: walk.rtte.state == TABLE post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
15.3.38.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state]
[level_bound, ipa_bound] < [rtt_walk, rtte_state]
15.3.38.3 Success conditions
| ID | Condition |
|---|---|
| rtt_state | GranuleAt(rtt).state == RTT |
| rtte_state | walk.rtte.state == TABLE |
| rtte_addr | walk.rtte.addr == rtt |
| rtte_c_ripas | pre: AddrIsProtected(ipa, realm) post: RttAllEntriesRipas(RttAt(rtt), unfoldrtte_pre.ripas) |
| rtte_c_state | RttAllEntriesState(RttAt(rtt), unfoldrtte_pre.state) |
| rtte_c_addr | pre: (unfoldrtte_pre.state != UNASSIGNED && unfoldrtte_pre.state != UNASSIGNED_NS) post: RttAllEntriesContiguous(RttAt(rtt), unfoldrtte_pre.addr, level) |
15.3.38.4 Footprint
| ID | Value |
|---|---|
| rtt_state | GranuleAt(rtt).state |
| rtte | RttEntryAt(walk.rtt_addr, entry_idx) |
15.3.39 RMI_RTT_DESTROY command
Destroys a primary RTT.
15.3.39.1 Interface
15.3.39.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400015E |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | Base of the IPA range described by the RTT |
| level | X3 | 63:0 | Int64 | RTT level |
15.3.39.1.2 Context
The RMI_RTT_DESTROY command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, level - 1, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| walk_top | Address | RttSkipNonLiveEntries( RttAt(walk.rtt_addr), walk.level, ipa) |
false | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
15.3.39.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| rtt | X1 | 63:0 | Address | PA of the RTT which was destroyed |
| top | X2 | 63:0 | Address | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
The rtt output value is valid only when the command
result is RMI_SUCCESS.
The values of the result and top output
values for different command outcomes are summarized in the following
table.
| Scenario | result | top | walk.rtte.state |
|---|---|---|---|
| Target RTT exists and is not live | RMI_SUCCESS | > ipa | Before execution: TABLE After execution: UNASSIGNED and RIPAS is DESTROYED |
| Missing RTT | (RMI_ERROR_RTT, < level) | > ipa | UNASSIGNED or UNASSIGNED_NS |
| Block mapping at lower level | (RMI_ERROR_RTT, < level) | == ipa | ASSIGNED or ASSIGNED_NS |
| Live RTT at target level | (RMI_ERROR_RTT, level) | == ipa | TABLE |
| RTT walk was not performed, due to any other command failure | Another error code | 0 | Unknown |
See also:
- Section 5.5.8
15.3.39.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| level_bound | pre: (!RttLevelIsValid(rd, level) || RttLevelIsStarting(rd, level)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsRttLevelAligned(ipa, level - 1) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: UInt(ipa) >= (2 ^ realm.ipa_width) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_walk | pre: walk.level < level - 1 post: (ResultEqual(result, RMI_ERROR_RTT, walk.level) && (top == walk_top)) |
| rtte_state | pre: walk.rtte.state != TABLE post: (ResultEqual(result, RMI_ERROR_RTT, walk.level) && (top == walk_top)) |
| rtt_live | pre: RttIsLive(RttAt(walk.rtte.addr)) post: (ResultEqual(result, RMI_ERROR_RTT, level) && (top == ipa)) |
15.3.39.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state]
[rtte_state] < [rtt_live]
[level_bound, ipa_bound] < [rtt_walk, rtte_state]
15.3.39.3 Success conditions
| ID | Condition |
|---|---|
| rtte_state | walk.rtte.state == UNASSIGNED |
| ripas | walk.rtte.ripas == DESTROYED |
| rtt_state | GranuleAt(walk.rtte.addr).state == DELEGATED |
| rtt | rtt == walk.rtte.addr |
| top | top == walk_top |
15.3.39.4 Footprint
| ID | Value |
|---|---|
| rtt_state | GranuleAt(walk.rtte.addr).state |
| rtte | RttEntryAt(walk.rtt_addr, entry_idx) |
15.3.40 RMI_RTT_FOLD command
Destroys a homogeneous primary RTT.
15.3.40.1 Interface
15.3.40.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000166 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | Base of the IPA range described by the RTT |
| level | X3 | 63:0 | Int64 | RTT level |
15.3.40.1.2 Context
The RMI_RTT_FOLD command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, level - 1, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| fold_pre | RmmRttEntry | RttFold( RttAt(walk.rtte.addr)) |
true | Result of folding RTT |
15.3.40.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| rtt | X1 | 63:0 | Address | PA of the RTT which was destroyed |
The rtt output value is valid only when the command
result is RMI_SUCCESS.
15.3.40.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| level_bound | pre: (!RttLevelIsValid(rd, level) || RttLevelIsStarting(rd, level)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsRttLevelAligned(ipa, level - 1) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: UInt(ipa) >= (2 ^ realm.ipa_width) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rtt_walk | pre: walk.level < level - 1 post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
| rtte_state | pre: walk.rtte.state != TABLE post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
| rtt_homo | pre: !RttIsHomogeneous(RttAt(walk.rtte.addr)) post: ResultEqual(result, RMI_ERROR_RTT, level) |
15.3.40.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state, rtt_homo]
[level_bound, ipa_bound] < [rtt_walk, rtte_state]
15.3.40.3 Success conditions
| ID | Condition |
|---|---|
| rtte_state | walk.rtte.state == fold_pre.state |
| rtte_addr | pre: (fold_pre.state != UNASSIGNED && fold_pre.state != UNASSIGNED_NS) post: walk.rtte.addr == fold_pre.addr |
| rtte_attr | pre: (fold_pre.state == ASSIGNED || fold_pre.state == ASSIGNED_NS) post: (walk.rtte.MemAttr == fold_pre.MemAttr && walk.rtte.S2APs2ap_base == fold_pre.S2APs2ap_base && walk.rtte.s2ap_overlay == fold_pre.s2ap_overlay) |
| rtte_ripas | pre: AddrIsProtected(ipa, realm) post: walk.rtte.ripas == fold_pre.ripas |
| rtt_state | GranuleAt(walk.rtte.addr).state == DELEGATED |
| rtt | rtt == walk.rtte.addr |
15.3.40.4 Footprint
| ID | Value |
|---|---|
| rtt_state | GranuleAt(walk.rtte.addr).state |
| rtte | RttEntryAt(walk.rtt_addr, entry_idx) |
15.3.41 RMI_RTT_INIT_RIPAS command
Set the RIPAS of a target IPA range to RAM, for a Realm in the REALM_NEW state.
15.3.41.1 Interface
15.3.41.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000168 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| base | X2 | 63:0 | Address | Base of target IPA region |
| top | X3 | 63:0 | Address | Top of target IPA region |
15.3.41.1.2 Context
The RMI_RTT_INIT_RIPAS command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm_pre | RmmRealm | RealmAt(rd) |
true | Realm |
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, base, RMM_RTT_PAGE_LEVEL, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| walk_top | Address | RttSkipEntriesWithRipas( RttAt(walk.rtt_addr), walk.level, base, top, FALSE) |
false | Top IPA of entries which have associated RIPAS values, starting from entry at which the RTT walk terminated |
15.3.41.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| out_top | X1 | 63:0 | Address | Top IPA of range whose RIPAS was modified |
The out_top output value is valid only when the command
result is RMI_SUCCESS.
When the out_top output value is valid, it is aligned to
the size of the address range described by the RTT entry at the level
where the RTT walk terminated.
15.3.41.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| size_valid | pre: UInt(top) <= UInt(base) post: ResultEqual(result, RMI_ERROR_INPUT) |
| top_bound | pre: !AddrIsProtected( ToAddress(UInt(top) - RMM_GRANULE_SIZE), realm_pre) post: ResultEqual(result, RMI_ERROR_INPUT) |
| realm_state | pre: realm_pre.state != REALM_NEW post: ResultEqual(result, RMI_ERROR_REALM) |
| base_align | pre: !AddrIsRttLevelAligned(base, walk.level) post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
| rtte_state | pre: walk.rtte.state != UNASSIGNED post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
| top_gran_align | pre: !AddrIsGranuleAligned(top) post: ResultEqual(result, RMI_ERROR_INPUT) |
| no_progress | pre: UInt(base) == UInt(walk_top) post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
15.3.41.2.1 Failure condition ordering
[rd_bound, rd_state] < [realm_state]
[rd_bound, rd_state] < [base_align, rtte_state]
[rd_bound, rd_state] < [no_progress]
[top_gran_align] < [no_progress]
15.3.41.3 Success conditions
| ID | Condition |
|---|---|
| rtte_ripas | RttEntriesInRangeRipas( RttAt(walk.rtt_addr), walk.level, base, walk_top, RAM) |
| rim | realm.measurements[0] == RimExtendRipas( realm_pre, base, walk_top, walk.level) |
| out_top | out_top == walk_top |
15.3.41.4 RMI_RTT_INIT_RIPAS extension of RIM
On successful execution of RMI_RTT_INIT_RIPAS, the new RIM value of the target Realm is calculated by the RMM as follows:
Allocate an RmmMeasurementDescriptorRipas data structure.
For each RTT entry in the range
[base, top)described by the RMI_RTT_INIT_RIPAS input values:
- Populate the measurement descriptor:
- Set the desc_type field to the descriptor type.
- Set the len field to the descriptor length.
- Set the base field to the IPA of the RTT entry.
- Set the top field to
Min(ipa + size, top), whereipais the IPA of the RTT entrysizeis the size in bytes of the IPA region described by the RTT entrytopis the input value provided to the command
- Using the RHA of the target Realm, compute the hash of the measurement descriptor. Set the RIM of the target Realm to this value, zero filling upper bytes if the RHA output is smaller than the size of the RIM.
15.3.41.5 Footprint
| ID | Value |
|---|---|
| rtte | RttAt(walk.rtt_addr) |
| rim | realm.measurements[0] |
15.3.42 RMI_RTT_MAP_UNPROTECTED command
Creates a mapping from an Unprotected IPA to a Non-secure PA in a primary RTT.
15.3.42.1 Interface
15.3.42.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400015F |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | IPA at which the Granule will be mapped in the target Realm |
| level | X3 | 63:0 | Int64 | RTT level |
| desc | X4 | 63:0 | Bits64 | RTTE descriptor |
The layout and encoding of fields in the desc input
value match “Attribute fields in stage 2 VMSAv8-64 Block and Page
descriptors” in Arm Architecture Reference
Manual for A-Profile architecture [3].
If the Realm has multiple Planes and is configured to use a single
RTT tree then the S2AP base index value, provided in the S2AP field of
the desc input value, uses the encoding defined in the
RmiUnprotectedS2AP type.
See also:
- Arm Architecture Reference Manual for A-Profile architecture [3]
- Section 5.5.11.3
- Section 14.100101
- Section 15.4.5048
15.3.42.1.2 Context
The RMI_RTT_MAP_UNPROTECTED command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, level, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| rtte | RmmRttEntry | RttDescriptorDecode(desc) |
false | RTT entry |
15.3.42.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.42.2 Failure conditions
| ID | Condition |
|---|---|
| attr_valid | pre: !RttDescriptorIsValidForUnprotected(desc) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| level_bound | pre: !RttLevelIsBlockOrPage(rd, level) post: ResultEqual(result, RMI_ERROR_INPUT) |
| addr_align | pre: !AddrIsRttLevelAligned(rtte.addr, level) post: ResultEqual(result, RMI_ERROR_INPUT) |
| addr_bound | pre: ((realm.feat_lpa2 == FEATURE_FALSE) && (UInt(rtte.addr) >= 2^48)) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsRttLevelAligned(ipa, level) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound |
pre: (UInt(ipa) >= (2 ^ realm.ipa_width)
|| AddrIsProtected(ipa, realm))
post: ResultEqual(result, RMI_ERROR_INPUT)
|
| rtt_walk | pre: walk.level < level post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
| rtte_state | pre: walk.rtte.state != UNASSIGNED_NS post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
15.3.42.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state]
[level_bound, ipa_bound] < [rtt_walk, rtte_state]
15.3.42.3 Success conditions
| ID | Condition |
|---|---|
| rtte_state | walk.rtte.state == ASSIGNED_NS |
| rtte_contents |
(walk.rtte.MemAttr == rtte.MemAttr
&& walk.rtte.S2APs2ap_base == rtte.S2APs2ap_base
&& walk.rtte.s2ap_overlay == 15
&& walk.rtte.addr == rtte.addr)
|
15.3.42.4 Footprint
| ID | Value |
|---|---|
| rtte | RttEntryAt(walk.rtt_addr, entry_idx) |
15.3.43 RMI_RTT_READ_ENTRY command
Reads an entry from a primary RTT.
See also:
- Section 5.5
15.3.43.1 Interface
15.3.43.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000161 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | Realm Address for which to read the RTTE |
| level | X3 | 63:0 | Int64 | RTT level at which to read the RTTE |
15.3.43.1.2 Context
The RMI_RTT_READ_ENTRY command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, level, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| rtte | RmmRttEntry | RttDescriptorDecode(desc) |
false | RTT entry value returned to Host |
15.3.43.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| walk_level | X1 | 63:0 | UInt64 | RTT level reached by the RTT walk |
| state | X2 | 7:0 | RmiRttEntryState | State of RTTE reached by the walk |
| desc | X3 | 63:0 | Bits64 | RTTE descriptor |
| ripas | X4 | 7:0 | RmiRipas | RIPAS of RTTE reached by the walk |
The following unused bits of RMI_RTT_READ_ENTRY output values MBZ: X2[63:8], X4[63:8].
The layout and encoding of fields in the rtte output
value match “Attribute fields in stage 2 VMSAv8-64 Block and Page
descriptors” in Arm Architecture Reference
Manual for A-Profile architecture [3].
See also:
15.3.43.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| level_bound | pre: !RttLevelIsValid(rd, level) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsRttLevelAligned(ipa, level) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound | pre: UInt(ipa) >= (2 ^ realm.ipa_width) post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.43.2.1 Failure condition ordering
The RMI_RTT_READ_ENTRY command does not have any failure condition orderings.
15.3.43.3 Success conditions
| ID | Condition |
|---|---|
| state | state == RttEntryStateToRmi(walk.rtte.state) |
| state_invalid | pre: (walk.rtte.state == UNASSIGNED || walk.rtte.state == UNASSIGNED_NS) post: (rtte.MemAttr == Zeros(3) && rtte.S2APs2ap_base == Zeros(2)0 && rtte.s2ap_overlay == 0 && rtte.addr == Zeros(ADDRESS_WIDTH)) |
| state_prot | pre: (walk.rtte.state == ASSIGNED || walk.rtte.state == TABLE) post: (rtte.MemAttr == Zeros(3) && rtte.S2APs2ap_base == Zeros(2)0 && rtte.s2ap_overlay == 0 && rtte.addr == walk.rtte.addr) |
| state_unprot | pre: walk.rtte.state == ASSIGNED_NS post: (rtte.MemAttr == walk.rtte.MemAttr && rtte.S2APs2ap_base == walk.rtte.S2APs2ap_base && rtte.s2ap_overlay == 0 && rtte.addr == walk.rtte.addr) |
| state_io | pre: (walk.rtte.state == ASSIGNED_DEV_PRIVATE || walk.rtte.state == ASSIGNED_DEV_SHARED) post: (rtte.MemAttr == walk.rtte.MemAttr && rtte.S2APs2ap_base == Zeros(2)0 && rtte.s2ap_overlay == 0 && rtte.addr == walk.rtte.addr) |
| ripas_prot | pre: (walk.rtte.state == UNASSIGNED || walk.rtte.state == ASSIGNED) post: ripas == RipasToRmi(walk.rtte.ripas) |
| ripas_unprot | pre: (walk.rtte.state == UNASSIGNED_NS &&|| walk.rtte.state == ASSIGNED_NS) post: ripas == RMI_EMPTY |
15.3.43.4 Footprint
The RMI_RTT_READ_ENTRY command does not have any footprint.
15.3.44 RMI_RTT_SET_RIPAS command
Completes a request made by the Realm to change the RIPAS of a target IPA range.
In RMI_RTT_SET_RIPAS, consider how to combine:
- Modification of a range of RTT entries in a single command, and
- Checking of output address and HIPAS values against rec.ripas_dev_pa and rec.ripas_dev_shared respectively.
15.3.44.1 Interface
15.3.44.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000169 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| rec_ptr | X2 | 63:0 | Address | PA of the target REC |
| base | X3 | 63:0 | Address | Base of target IPA region |
| top | X4 | 63:0 | Address | Top of target IPA region |
15.3.44.1.2 Context
The RMI_RTT_SET_RIPAS command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm_pre | RmmRealm | RealmAt(rd) |
true | Realm |
| rec | RmmRec | RecAt(rec_ptr) |
false | REC |
| walk | RmmRttWalkResult | RttWalk( rd, base, RMM_RTT_PAGE_LEVEL, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| ripas_pre | RmmRipas | walk.rtte.ripas |
true | RIPAS before the command executed |
| walk_top_pre | Address | RttSkipEntriesWithRipas( RttAt(walk.rtt_addr), walk.level, base, top, rec.ripas_destroyed != CHANGE_DESTROYED) |
true | Top IPA of entries which have associated RIPAS values, starting from entry at which the RTT walk terminated |
15.3.44.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| out_top | X1 | 63:0 | Address | Top IPA of range whose RIPAS was modified |
The out_top output value is valid only when the command
result is RMI_SUCCESS.
15.3.44.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_align | pre: !AddrIsGranuleAligned(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_bound | pre: !PaIsDelegable(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_gran_state | pre: GranuleAt(rec_ptr).state != REC post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_state | pre: rec.state == REC_RUNNING post: ResultEqual(result, RMI_ERROR_REC) |
| rec_owner | pre: rec.owner != rd post: ResultEqual(result, RMI_ERROR_REC) |
| size_valid | pre: UInt(top) <= UInt(base) post: ResultEqual(result, RMI_ERROR_INPUT) |
| base_bound | pre: base != rec.ripas_addr post: ResultEqual(result, RMI_ERROR_INPUT) |
| top_bound | pre: UInt(top) > UInt(rec.ripas_top) post: ResultEqual(result, RMI_ERROR_INPUT) |
| base_align | pre: (!AddrIsRttLevelAligned(base, walk.level) && ripas_pre != rec.ripas_value) post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
| top_gran_align | pre: !AddrIsGranuleAligned(top) post: ResultEqual(result, RMI_ERROR_INPUT) |
| no_progress |
pre: (UInt(base) == UInt(walk_top_pre)
&& ripas_pre != rec.ripas_value)
post: ResultEqual(result, RMI_ERROR_RTT, walk.level)
|
| dev_pa |
pre: Output address does not match value required by
rec.ripas_dev_pa.
post: ResultEqual(result, RMI_ERROR_RTT, walk.level)
|
| dev_shared |
pre: HIPAS value does not match value required by
rec.ripas_dev_shared.
post: ResultEqual(result, RMI_ERROR_RTT, walk.level)
|
| aux_live | pre: AddrRangeIsAuxLive(base, top, realm_pre) post: ResultEqual(result, RMI_ERROR_RTT, walk.level) |
15.3.44.2.1 Failure condition ordering
[rd_bound, rd_state] < [base_align]
[rd_bound, rd_state] < [no_progress]
[rec_bound, rec_gran_state] < [rec_state, rec_owner]
[base_bound] < [base_align]
[top_gran_align] < [no_progress]
15.3.44.3 Success conditions
| ID | Condition |
|---|---|
| rtte_ripas | RttEntriesInRangeRipas( RttAt(walk.rtt_addr), walk.level, base, walk_top_pre, rec.ripas_value) |
| ripas_addr | rec.ripas_addr == MinAddress(top, walk_top_pre) |
| out_top | out_top == MinAddress(top, walk_top_pre) |
15.3.44.4 Footprint
| ID | Value |
|---|---|
| rtte | RttAt(walk.rtt_addr) |
| ripas_addr | rec.ripas_addr |
15.3.45 RMI_RTT_SET_S2AP command
Completes a request made by the Realm to change the S2AP of a target IPA range.
See also:
- Section 10.3.2.4
15.3.45.1 Interface
15.3.45.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400018B |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| rec_ptr | X2 | 63:0 | Address | PA of the target REC |
| base | X3 | 63:0 | Address | Base of target IPA region |
| top | X4 | 63:0 | Address | Top of target IPA region |
15.3.45.1.2 Context
The RMI_RTT_SET_S2AP command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm_pre | RmmRealm | RealmAt(rd) |
true | Realm |
| rec | RmmRec | RecAt(rec_ptr) |
false | REC |
| walksnot_aligned | RmmRttWalkResultRmmRttWalkNotAligned[4] | RttWalkAllRttWalkAnyNotAligned( rd, base, top, RMM_RTT_PAGE_LEVEL) |
false | RTT walk resultsresult which is not aligned to page level |
15.3.45.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| out_top | X1 | 63:0 | Address | Top IPA of range whose S2AP was modified |
| rtt_tree | X2 | 63:0 | UInt64 | Index of RTT tree in which base alignment check failed |
If result is RMI_ERROR_RTT or RMI_ERROR_RTT_AUX then the
following are true:
out_topis the IPA of the RTTE at which the base alignment check failed.rtt_treeis the index of the RTT in which the base alignment check failed.
15.3.45.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_align | pre: !AddrIsGranuleAligned(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_bound | pre: !PaIsDelegable(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_gran_state | pre: GranuleAt(rec_ptr).state != REC post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_state | pre: rec.state == REC_RUNNING post: ResultEqual(result, RMI_ERROR_REC) |
| rec_owner | pre: rec.owner != rd post: ResultEqual(result, RMI_ERROR_REC) |
| size_valid | pre: UInt(top) <= UInt(base) post: ResultEqual(result, RMI_ERROR_INPUT) |
| base_bound | pre: base != rec.s2ap_addr post: ResultEqual(result, RMI_ERROR_INPUT) |
| top_bound | pre: UInt(top) > UInt(rec.s2ap_top) post: ResultEqual(result, RMI_ERROR_INPUT) |
| top_gran_align | pre: !AddrIsGranuleAligned(top) post: ResultEqual(result, RMI_ERROR_INPUT) |
| base_align_pri | pre: base_align(not_aligned.valid == RMM_TRUE && !AddrRangeIsWithin( base, top, AlignDownToRttLevel( not_aligned.addr, not_aligned.walk.level ), AlignUpToRttLevel( not_aligned.addr, not_aligned.walk.level )) && not_aligned.index == RMM_RTT_TREE_PRIMARY && not_aligned.walk.rtte.s2ap_overlay != rec.s2ap_overlay) post: ResultEqual( result, RMI_ERROR_RTT, walks[not_aligned.walk.level) |
| base_align_aux | pre: (not_aligned.valid == RMM_TRUE && !AddrRangeIsWithin( base, top, AlignDownToRttLevel( not_aligned.addr, not_aligned.walk.level ), AlignUpToRttLevel( not_aligned.addr, not_aligned.walk.level )) && not_aligned.index != RMM_RTT_TREE_PRIMARY] && not_aligned.levelwalk.rtte.s2ap_overlay != rec.s2ap_overlay) base_align_aux pre: base_align > RMM_RTT_TREE_PRIMARY post: ResultEqual( result, RMI_ERROR_RTT_AUX, walks[base_align]not_aligned.walk.level) |
15.3.45.2.1 Failure condition ordering
The RMI_RTT_SET_S2AP command does not have any failure condition orderings.
15.3.45.3 Success conditions
The RMI_RTT_SET_S2AP command does not have any success conditions.
15.3.45.4 Footprint
The RMI_RTT_SET_S2AP command does not have any footprint.
15.3.46 RMI_RTT_UNMAP_UNPROTECTED command
Removes a mapping at an Unprotected IPA.
15.3.46.1 Interface
15.3.46.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000162 |
| rd | X1 | 63:0 | Address | PA of the RD for the target Realm |
| ipa | X2 | 63:0 | Address | IPA at which the Granule is mapped in the target Realm |
| level | X3 | 63:0 | Int64 | RTT level |
15.3.46.1.2 Context
The RMI_RTT_UNMAP_UNPROTECTED command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| walk | RmmRttWalkResult | RttWalk( rd, ipa, level, RMM_RTT_TREE_PRIMARY) |
false | RTT walk result |
| entry_idx | UInt64 | RttEntryIndex( ipa, walk.level) |
false | RTTE index |
| walk_top | Address | RttSkipNonLiveEntries( RttAt(walk.rtt_addr), walk.level, ipa) |
false | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
15.3.46.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| top | X1 | 63:0 | Address | Top IPA of non-live RTT entries, from entry at which the RTT walk terminated |
The values of the result and top output
values for different command outcomes are summarized in the following
table.
| Scenario | result | top | walk.rtte.state |
|---|---|---|---|
ipa is mapped at the target level |
RMI_SUCCESS | > ipa | Before execution: ASSIGNED_NS | | | | | After execution: UNASSIGNED_NS | | Before execution: ASSIGNED_NS After execution: UNASSIGNED_NS||
ipa is not mapped |
(RMI_ERROR_RTT, <= level) | > ipa | UNASSIGNED_NS | | UNASSIGNED_NS||
ipa is mapped at a lower level |
(RMI_ERROR_RTT, < level) | == ipa | ASSIGNED_NS | | ASSIGNED_NS||
| RTT walk was not performed, due to any other command failure | Another error code | 0 | Unknown |
See also:
- Section 5.5.8
15.3.46.2 Failure conditions
| ID | Condition |
|---|---|
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| level_bound | pre: !RttLevelIsBlockOrPage(rd, level) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_align | pre: !AddrIsRttLevelAligned(ipa, level) post: ResultEqual(result, RMI_ERROR_INPUT) |
| ipa_bound |
pre: (UInt(ipa) >= (2 ^ realm.ipa_width)
|| AddrIsProtected(ipa, realm))
post: ResultEqual(result, RMI_ERROR_INPUT)
|
| rtt_walk | pre: walk.level < level post: (ResultEqual(result, RMI_ERROR_RTT, walk.level) && (top == walk_top)) |
| rtte_state | pre: walk.rtte.state != ASSIGNED_NS post: (ResultEqual(result, RMI_ERROR_RTT, walk.level) && (top == walk_top)) |
15.3.46.2.1 Failure condition ordering
[rd_bound, rd_state] < [rtt_walk, rtte_state]
[level_bound, ipa_bound] < [rtt_walk, rtte_state]
15.3.46.3 Success conditions
| ID | Condition |
|---|---|
| rtte_state | walk.rtte.state == UNASSIGNED_NS |
| top | top == walk_top |
15.3.46.4 Footprint
| ID | Value |
|---|---|
| rtte | RttEntryAt(walk.rtt_addr, entry_idx) |
15.3.47 RMI_VDEV_ABORT command
Abort device communication associated with a VDEV.
See also:
- Section 9
15.3.47.1 Interface
15.3.47.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000185 |
| vdev_ptr | X1 | 63:0 | Address | PA of the VDEV |
15.3.47.1.2 Context
The RMI_VDEV_ABORT command operates on the following context.
15.3.47.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.47.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| vdev_align | pre: !AddrIsGranuleAligned(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_bound | pre: !PaIsDelegable(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_gran_state | pre: GranuleAt(vdev_ptr).state != VDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_state | pre: vdev.state != VDEV_COMMUNICATING post: ResultEqual(result, RMI_ERROR_DEVICE) |
15.3.47.2.1 Failure condition ordering
[da_supp] < [vdev_align, vdev_bound, vdev_gran_state]
[vdev_gran_state] < [vdev_state]
15.3.47.3 Success conditions
| ID | Condition |
|---|---|
| state | vdev.state == VDEV_READY |
| comm_state | vdev.comm_state == DEV_COMM_IDLE |
15.3.47.4 Footprint
| ID | Value |
|---|---|
| state | vdev.state |
| comm_state | vdev.comm_state |
15.3.48 RMI_VDEV_AUX_COUNT command
Get number of auxiliary Granules required for a VDEV.
15.3.48.1 Interface
15.3.48.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000160 |
| pdev_flags | X1 | 63:0 | Bits64 | PDEV flags |
| vdev_flags | X2 | 63:0 | Bits64 | VDEV flags |
15.3.48.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| aux_count | X1 | 63:0 | UInt64 | Number of auxiliary Granules required for a VDEV |
15.3.48.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
15.3.48.3 Success conditions
| ID | Condition |
|---|---|
| aux_count | aux_count == VdevAuxCount( RmiPdevFlagsDecode(pdev_flags), RmiVdevFlagsDecode(vdev_flags)) |
15.3.48.4 Footprint
The RMI_VDEV_AUX_COUNT command does not have any footprint.
15.3.49 RMI_VDEV_COMMUNICATE command
Perform device communication associated with a VDEV.
See also:
- Section 9
15.3.49.1 Interface
15.3.49.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000186 |
| pdev_ptr | X1 | 63:0 | Address | PA of the PDEV |
| vdev_ptr | X2 | 63:0 | Address | PA of the VDEV |
| data_ptr | X3 | 63:0 | Address | PA of the communication data structure |
15.3.49.1.2 Context
The RMI_VDEV_COMMUNICATE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| pdev | RmmPdev | PdevAt(pdev_ptr) |
false | PDEV |
| vdev | RmmVdev | VdevAt(vdev_ptr) |
false | VDEV |
| data | RmiDevCommData | RmiDevCommDataAt(data_ptr) |
false | Device communication object |
| num_vdevs_pre | UInt64 | pdev.num_vdevs |
true | Number of VDEVs associated with the PDEV |
15.3.49.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.49.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_gran_state | pre: GranuleAt(pdev_ptr).state != PDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_align | pre: !AddrIsGranuleAligned(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_bound | pre: !PaIsDelegable(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_gran_state | pre: GranuleAt(vdev_ptr).state != VDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_align | pre: !AddrIsGranuleAligned(data_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_bound | pre: !PaIsDelegable(data_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| data_pas | pre: !GranuleAccessPermitted(data_ptr, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| req_align | pre: !AddrIsGranuleAligned(data.enter.req_addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| req_bound | pre: !PaIsDelegable(data.enter.req_addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| req_pas | pre: !GranuleAccessPermitted(data.enter.req_addr, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| resp_align | pre: !AddrIsGranuleAligned(data.enter.resp_addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| resp_bound | pre: !PaIsDelegable(data.enter.resp_addr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| resp_pas | pre: !GranuleAccessPermitted(data.enter.resp_addr, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| resp_len | pre: data.enter.resp_len > RMM_GRANULE_SIZE post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_pdev | pre: vdev.pdev != pdev_ptr post: ResultEqual(result, RMI_ERROR_DEVICE) |
| vdev_state | pre: (vdev.state != VDEV_COMMUNICATING && vdev.state != VDEV_STOPPING) post: ResultEqual(result, RMI_ERROR_DEVICE) |
15.3.49.2.1 Failure condition ordering
[da_supp] < [pdev_align, pdev_bound, pdev_gran_state, vdev_align,
vdev_bound, vdev_gran_state, data_align, data_bound, data_pas,
req_align, req_bound, req_pas, resp_align, resp_bound, resp_pas,
resp_len]
[pdev_gran_state, vdev_gran_state] < [vdev_pdev, vdev_state]
15.3.49.3 Success conditions
| ID | Condition |
|---|---|
| comm_state | vdev.comm_state == DeviceCommunicate(vdev, data) |
| error | pre: (DeviceCommunicate(vdev, data) == DEV_COMM_ERROR && vdev.state == VDEV_COMMUNICATING) post: vdev.state == VDEV_ERROR |
| ready | pre: (DeviceCommunicate(vdev, data) == DEV_COMM_IDLE && vdev.state == VDEV_COMMUNICATING) post: vdev.state == VDEV_READY |
| stopped | pre: (DeviceCommunicate(vdev, data) != DEV_COMM_ACTIVE && vdev.state == VDEV_STOPPING) post: (vdev.state == VDEV_STOPPED && pdev.num_vdevs == num_vdevs_pre - 1) |
15.3.49.4 Footprint
| ID | Value |
|---|---|
| state | vdev.state |
| comm_state | vdev.comm_state |
15.3.50 RMI_VDEV_COMPLETE command
Completes a pending VDEV request.
15.3.50.1 Interface
15.3.50.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400018E |
| rec_ptr | X1 | 63:0 | Address | PA of the REC |
| vdev_ptr | X2 | 63:0 | Address | PA of the VDEV |
15.3.50.1.2 Context
The RMI_VDEV_COMPLETE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| rec | RmmRec | RecAt(rec_ptr) |
false | REC |
| vdev | RmmVdev | VdevAt(vdev_ptr) |
false | VDEV |
15.3.50.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.50.2 Failure conditions
| ID | Condition |
|---|---|
| rec_align | pre: !AddrIsGranuleAligned(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rec_bound | pre: !PaIsDelegable(rec_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| recv_state | pre: GranuleAt(rec_ptr).state != REC post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_align | pre: !AddrIsGranuleAligned(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_bound | pre: !PaIsDelegable(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_state | pre: GranuleAt(vdev_ptr).state != VDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| pending | pre: rec.pending != REC_PENDING_VDEV_REQUEST post: ResultEqual(result, RMI_ERROR_INPUT) |
| owner | pre: rec.owner != vdev.realm post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_id | pre: rec.vdev_id != vdev.vdev_id post: ResultEqual(result, RMI_ERROR_INPUT) |
| inst_id | pre: (rec.inst_id_valid == RMM_TRUE && rec.inst_id != vdev.inst_id) post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.50.2.1 Failure condition ordering
The RMI_VDEV_COMPLETE command does not have any failure condition orderings.
15.3.50.3 Success conditions
| ID | Condition |
|---|---|
| pending | rec.pending == REC_PENDING_NONE |
15.3.50.4 Footprint
| ID | Value |
|---|---|
| pend | rec.pending |
15.3.51 RMI_VDEV_CREATE command
Create a VDEV.
See also:
- Section 9
15.3.51.1 Interface
15.3.51.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000187 |
| rd | X1 | 63:0 | Address | PA of the RD |
| pdev_ptr | X2 | 63:0 | Address | PA of the PDEV |
| vdev_ptr | X3 | 63:0 | Address | PA of the VDEV |
| params_ptr | X4 | 63:0 | Address | PA of VDEV parameters |
15.3.51.1.2 Context
The RMI_VDEV_CREATE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm_pre | RmmRealm | RealmAt(rd) |
true | Realm |
| realm | RmmRealm | RealmAt(rd) |
false | Realm |
| pdev | RmmPdev | PdevAt(pdev_ptr) |
false | PDEV |
| num_vdevs_pre | UInt64 | pdev.num_vdevs |
true | Number of VDEVs associated with the PDEV |
| vdev | RmmVdev | VdevAt(vdev_ptr) |
false | VDEV |
| params | RmiVdevParams | RmiVdevParamsAt(params_ptr) |
false | VDEV parameters |
| num_aux | UInt64 | VdevAuxCount( PdevFlags(pdev), params.flags) |
false | Number of auxiliary Granules |
| rdev | RmmRdev | RdevFromIds( realm, params.vdev_id, realm_pre.num_vdevs) |
false | RDEV |
15.3.51.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.51.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_gran_state | pre: GranuleAt(pdev_ptr).state != PDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_state | pre: pdev.state != PDEV_READY post: ResultEqual(result, RMI_ERROR_DEVICE) |
| vdev_align | pre: !AddrIsGranuleAligned(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_bound | pre: !PaIsDelegable(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_gran_state | pre: GranuleAt(vdev_ptr).state != DELEGATED post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_align | pre: !AddrIsGranuleAligned(params_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_bound | pre: !PaIsDelegable(params_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_pas | pre: !GranuleAccessPermitted(params_ptr, PAS_NS) post: ResultEqual(result, RMI_ERROR_INPUT) |
| params_valid | pre: !RmiVdevParamsIsValid(params_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| da_en | pre: realm.feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_REALM) |
| num_aux | pre: params.num_aux != num_aux post: ResultEqual(result, RMI_ERROR_INPUT) |
| aux_align | pre: !AuxAligned32(params.aux, params.num_aux) post: ResultEqual(result, RMI_ERROR_INPUT) |
| aux_alias | pre: AuxAlias32(vdev_ptr, params.aux, params.num_aux) post: ResultEqual(result, RMI_ERROR_INPUT) |
| aux_state | pre: !AuxStateEqual32( params.aux, params.num_aux, DELEGATED) post: ResultEqual(result, RMI_ERROR_INPUT) |
| tdi_id_free | pre: !TdiIdIsFree(params.tdi_id, pdev.segment_id) post: ResultEqual(result, RMI_ERROR_INPUT) |
| tdi_id_bound |
pre: (UInt(params.tdi_id) < pdev.rid_base
|| UInt(params.tdi_id) >= pdev.rid_top)
post: ResultEqual(result, RMI_ERROR_INPUT)
|
15.3.51.2.1 Failure condition ordering
[da_supp] < [rd_align, rd_bound, pdev_bound, vdev_align, vdev_bound,
vdev_gran_state, params_align, params_bound, params_pas,
params_valid, num_aux, aux_align, aux_alias, aux_state]
[da_supp] < [pdev_gran_state]
[da_supp] < [rd_state]
[pdev_gran_state] < [pdev_state]
[rd_state] < [da_en]
15.3.51.3 Success conditions
| ID | Condition |
|---|---|
| pdev_num_vdevs | pdev.num_vdevs == num_vdevs_pre + 1 |
| gran_state | GranuleAt(vdev_ptr).state == VDEV |
| vdev_id | vdev.vdev_id == params.vdev_id |
| tdi_id | vdev.tdi_id == params.tdi_id |
| pdev | vdev.pdev == pdev_ptr |
| realm | vdev.realm == rd |
| state | vdev.state == VDEV_READY |
| comm_state | vdev.comm_state == DEV_COMM_IDLE |
| rdev_state | rdev.state == RDEV_NEW |
| rdev_op | rdev.operation == RDEV_OP_NONE |
| rdev_vdev_ptr | rdev.vdev_ptr == vdev_ptr |
| aux | AuxEqual32(vdev.aux, params.aux, num_aux) |
| num_aux | vdev.num_aux == num_aux |
| aux_state | AuxStateEqual32( vdev.aux, num_aux, VDEV_AUX) |
| tdi_id_used | !TdiIdIsFree(params.tdi_id, pdev.segment_id) |
| inst_id | vdev.inst_id == realm_pre.num_vdevs |
| realm_num_vdevs | realm.num_vdevs == realm_pre.num_vdevs + 1 |
15.3.51.4 Footprint
15.3.52 RMI_VDEV_DESTROY command
Destroy a VDEV.
See also:
- Section 9
15.3.52.1 Interface
15.3.52.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000188 |
| rd | X1 | 63:0 | Address | PA of the RD |
| pdev_ptr | X2 | 63:0 | Address | PA of the PDEV |
| vdev_ptr | X3 | 63:0 | Address | PA of the VDEV |
15.3.52.1.2 Context
The RMI_VDEV_DESTROY command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| vdev_pre | RmmVdev | VdevAt(vdev_ptr) |
true | VDEV |
| pdev_pre | RmmPdev | PdevAt(pdev_ptr) |
true | PDEV |
15.3.52.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.52.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| rd_align | pre: !AddrIsGranuleAligned(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_bound | pre: !PaIsDelegable(rd) post: ResultEqual(result, RMI_ERROR_INPUT) |
| rd_gran_state | pre: GranuleAt(rd).state != RD post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_align | pre: !AddrIsGranuleAligned(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_bound | pre: !PaIsDelegable(pdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| pdev_gran_state | pre: GranuleAt(pdev_ptr).state != PDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_align | pre: !AddrIsGranuleAligned(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_bound | pre: !PaIsDelegable(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_gran_state | pre: GranuleAt(vdev_ptr).state != VDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_realm | pre: vdev_pre.realm != rd post: ResultEqual(result, RMI_ERROR_DEVICE) |
| vdev_pdev | pre: vdev_pre.pdev != pdev_ptr post: ResultEqual(result, RMI_ERROR_DEVICE) |
| vdev_state | pre: vdev_pre.state != VDEV_STOPPED post: ResultEqual(result, RMI_ERROR_DEVICE) |
15.3.52.2.1 Failure condition ordering
[da_supp] < [rd_align, rd_bound, rd_gran_state, pdev_align,
pdev_bound, pdev_gran_state, vdev_align, vdev_bound,
vdev_gran_state]
[rd_gran_state, pdev_gran_state, vdev_gran_state] < [vdev_realm,
vdev_pdev, vdev_state]
15.3.52.3 Success conditions
| ID | Condition |
|---|---|
| gran_state | GranuleAt(vdev_ptr).state == DELEGATED |
| aux_state | AuxStateEqual32( vdev_pre.aux, vdev_pre.num_aux, DELEGATED) |
| tdi_id_free | TdiIdIsFree(vdev_pre.tdi_id, pdev_pre.segment_id) |
15.3.52.4 Footprint
15.3.53 RMI_VDEV_GET_STATE command
Get state of a VDEV.
See also:
- Section 9
15.3.53.1 Interface
15.3.53.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000189 |
| vdev_ptr | X1 | 63:0 | Address | PA of the VDEV |
15.3.53.1.2 Context
The RMI_VDEV_GET_STATE command operates on the following context.
15.3.53.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| state | X1 | 7:0 | RmiVdevState | VDEV state |
The following unused bits of RMI_VDEV_GET_STATE output values MBZ: X1[63:8].
15.3.53.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| vdev_align | pre: !AddrIsGranuleAligned(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_bound | pre: !PaIsDelegable(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_gran_state | pre: GranuleAt(vdev_ptr).state != VDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
15.3.53.2.1 Failure condition ordering
[da_supp] < [vdev_align, vdev_bound, vdev_gran_state]
15.3.53.3 Success conditions
| ID | Condition |
|---|---|
| state | Equal(state, vdev.state) |
15.3.53.4 Footprint
The RMI_VDEV_GET_STATE command does not have any footprint.
15.3.54 RMI_VDEV_STOP command
Stop a VDEV.
See also:
- Section 9
15.3.54.1 Interface
15.3.54.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC400018A |
| vdev_ptr | X1 | 63:0 | Address | PA of the VDEV |
15.3.54.1.2 Context
The RMI_VDEV_STOP command operates on the following context.
15.3.54.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
15.3.54.2 Failure conditions
| ID | Condition |
|---|---|
| da_supp | pre: ImplFeatures().feat_da != FEATURE_TRUE post: ResultEqual(result, RMI_ERROR_NOT_SUPPORTED) |
| vdev_align | pre: !AddrIsGranuleAligned(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_bound | pre: !PaIsDelegable(vdev_ptr) post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_gran_state | pre: GranuleAt(vdev_ptr).state != VDEV post: ResultEqual(result, RMI_ERROR_INPUT) |
| vdev_state | pre: (vdev.state != VDEV_READY && vdev.state != VDEV_ERROR) post: ResultEqual(result, RMI_ERROR_DEVICE) |
15.3.54.2.1 Failure condition ordering
[da_supp] < [vdev_align, vdev_bound, vdev_gran_state]
[vdev_gran_state] < [vdev_state]
15.3.54.3 Success conditions
| ID | Condition |
|---|---|
| state | vdev.state == VDEV_STOPPING |
| comm_state | vdev.comm_state == DEV_COMM_PENDING |
15.3.54.4 Footprint
| ID | Value |
|---|---|
| state | vdev.state |
| comm_state | vdev.comm_state |
15.3.55 RMI_VERSION command
Allows the Host and the RMM to determine whether there exists a mutually acceptable revision of the RMM via which the two components can communicate.
On calling this command, the Host provides a requested RMI version.
The output values include a status code and two revisions which are supported by the RMM: a lower revision and a higher revision.
- The higher revision value is the highest interface revision which is supported by the RMM.
- The lower revision is less than or equal to the higher revision.
The status code and lower revision output values indicate which of the following is true, in order of precedence:
The RMM supports an interface revision which is compatible with the requested revision.
- The status code is RMI_SUCCESS.
- The lower revision is equal to the requested revision.
The RMM does not support an interface revision which is compatible with the requested revision The RMM supports an interface revision which is incompatible with and less than the requested revision.
- The status code is RMI_ERROR_INPUT.
- The lower revision is the highest interface revision which is both less than the requested revision and supported by the RMM.
The RMM does not support an interface revision which is compatible with the requested revision The RMM supports an interface revision which is incompatible with and greater than the requested revision.
- The status code is RMI_ERROR_INPUT.
- The lower revision is equal to the higher revision.
15.3.55.1 Interface
15.3.55.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000150 |
| req | X1 | 63:0 | RmiInterfaceVersion | Requested interface revision |
15.3.55.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RmiCommandReturnCode | Command return status |
| lower | X1 | 63:0 | RmiInterfaceVersion | Lower implemented interface revision |
| higher | X2 | 63:0 | RmiInterfaceVersion | Higher implemented interface revision |
15.3.55.2 Failure conditions
The RMI_VERSION command does not have any failure conditions.
15.3.55.3 Success conditions
The RMI_VERSION command does not have any success conditions.
15.3.55.4 Footprint
The RMI_VERSION command does not have any footprint.
15.4 RMI types
This section defines types which are used in the RMI interface.
15.4.1 RmiAddressRange type
The RmiAddressRange structure contains address range.
The RmiAddressRange structure is a concrete type.
The width of the RmiAddressRange structure is 16 (0x10)
bytes.
The members of the RmiAddressRange structure are shown in the following table.
The RmiAddressRange structure is used in the following types:
15.4.2 RmiBoolean type
The RmiBoolean enumeration represents a boolean value.
The RmiBoolean enumeration is a concrete type.
The width of the RmiBoolean enumeration is 1 bits.
The values of the RmiBoolean enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_FALSE | False |
| 1 | RMI_TRUE | True |
The RmiBoolean enumeration is used in the following types:
15.4.3 RmiCommandReturnCode type
The RmiCommandReturnCode fieldset contains a return code from an RMI command.
The RmiCommandReturnCode fieldset is a concrete type.
The width of the RmiCommandReturnCode fieldset is 64 bits.
See also:
- Section 12
The fields of the RmiCommandReturnCode fieldset are shown in the following diagram.
The fields of the RmiCommandReturnCode fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| status | 7:0 | Status of the command | RmiStatusCode |
| index | 15:8 | Index which identifies the reason for a command failure | UInt8 |
| 63:16 | Reserved | MBZ |
15.4.4 RmiDataFlags type
The RmiDataFlags fieldset contains flags provided by the Host during DATA Granule creation.
The RmiDataFlags fieldset is a concrete type.
The width of the RmiDataFlags fieldset is 64 bits.
The fields of the RmiDataFlags fieldset are shown in the following diagram.
The fields of the RmiDataFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| measure | 0 | Whether to measure DATA Granule contents | RmiDataMeasureContent |
| 63:1 | Reserved | SBZ |
15.4.5 RmiDataMeasureContent type
The RmiDataMeasureContent enumeration represents whether to measure DATA Granule contents.
The RmiDataMeasureContent enumeration is a concrete type.
The width of the RmiDataMeasureContent enumeration is 1 bits.
The values of the RmiDataMeasureContent enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_NO_MEASURE_CONTENT | Do not measure DATA Granule contents. |
| 1 | RMI_MEASURE_CONTENT | Measure DATA Granule contents. |
The RmiDataMeasureContent enumeration is used in the following types:
15.4.6 RmiDevCommData type
The RmiDevCommData structure contains data structure shared between Host and RMM for device communication.
The RmiDevCommData structure is a concrete type.
The width of the RmiDevCommData structure is 4096
(0x1000) bytes.
The members of the RmiDevCommData structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| enter | 0x0 |
RmiDevCommEnter | Entry information |
| exit | 0x800 |
RmiDevCommExit | Exit information |
Unused bits of the RmiDevCommData structure SBZ.
15.4.7 RmiDevCommEnter type
The RmiDevCommEnter structure contains data passed from the Host to the RMM during device communication.
The RmiDevCommEnter structure is a concrete type.
The width of the RmiDevCommEnter structure is 256
(0x100) bytes.
See also:
- Section 9.2.5.2
The members of the RmiDevCommEnter structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| status | 0x0 |
RmiDevCommStatus | Status of device transaction |
| req_addr | 0x8 |
Address | Address of request buffer |
| resp_addr | 0x10 |
Address | Address of response buffer |
| resp_len | 0x18 |
UInt64 | Amount of valid data in response buffer in bytes |
Unused bits of the RmiDevCommEnter structure SBZ.
The RmiDevCommEnter structure is used in the following types:
15.4.8 RmiDevCommExit type
The RmiDevCommExit structure contains data passed from the RMM to the Host during device communication.
The RmiDevCommExit structure is a concrete type.
The width of the RmiDevCommExit structure is 256 (0x100)
bytes.
See also:
- Section 9.2.5.1
The members of the RmiDevCommExit structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| flags | 0x0 |
RmiDevCommExitFlags | Flags indicating action(s) which the Host is requested to perform |
| cache_offset | 0x8 |
UInt64 | If flags.cache is true, offset in the device response buffer to the start of data to be cached, in bytes |
| cache_len | 0x10 |
UInt64 | If flags.cache is true, amount of data to be cached, in bytes |
| protocol | 0x18 |
RmiDevCommProtocol | If flags.send is true, protocol to use |
| req_len | 0x20 |
UInt64 | If flags.send is true, amount of valid data in request buffer in bytes |
| timeout | 0x28 |
UInt64 | If flags.wait is true, amount of time to wait for device response in milliseconds |
Unused bits of the RmiDevCommExit structure MBZ.
The RmiDevCommExit structure is used in the following types:
15.4.9 RmiDevCommExitFlags type
The RmiDevCommExitFlags fieldset contains flags provided by the RMM during a device transaction.
The RmiDevCommExitFlags fieldset is a concrete type.
The width of the RmiDevCommExitFlags fieldset is 64 bits.
The fields of the RmiDevCommExitFlags fieldset are shown in the following diagram.
The fields of the RmiDevCommExitFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| cache | 0 | Whether the Host is requested to cache data from the device response buffer | RmiBoolean |
| send | 1 | Whether the Host is requested to send data from the device request buffer to the device | RmiBoolean |
| wait | 2 | Whether the Host is requested to waitRMM is waiting for a response from the device | RmiBoolean |
| multi | 3 | Whether the device transaction contains more than one (device request, device response) tuple | RmiBoolean |
| 63:4 | Reserved | MBZ |
The RmiDevCommExitFlags fieldset is used in the following types:
15.4.10 RmiDevCommProtocol type
The RmiDevCommProtocol enumeration represents protocol used for device communication.
The RmiDevCommProtocol enumeration is a concrete type.
The width of the RmiDevCommProtocol enumeration is 8 bits.
The values of the RmiDevCommProtocol enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_PROTOCOL_SPDM | SPDM |
| 1 | RMI_PROTOCOL_SECURE_SPDM | Secure SPDM |
Unused encodings for the RmiDevCommProtocol enumeration are reserved for use by future versions of this specification.
The RmiDevCommProtocol enumeration is used in the following types:
15.4.11 RmiDevCommStatus type
The RmiDevCommStatus enumeration represents status passed from the Host to the RMM during device communication.
The RmiDevCommStatus enumeration is a concrete type.
The width of the RmiDevCommStatus enumeration is 8 bits.
The values of the RmiDevCommStatus enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_DEV_COMM_SUCCESS | Either:
|
| 1 | RMI_DEV_COMM_ERROR | Either:
|
| 2 | RMI_DEV_COMM_NONE | There are no pending actions for the device. |
Unused encodings for the RmiDevCommStatus enumeration are reserved for use by future versions of this specification.
The RmiDevCommStatus enumeration is used in the following types:
15.4.12 RmiDevDelegateFlags type
The RmiDevDelegateFlags fieldset contains flags provided by the Host during device memory Granule delegation.
The RmiDevDelegateFlags fieldset is a concrete type.
The width of the RmiDevDelegateFlags fieldset is 64 bits.
The fields of the RmiDevDelegateFlags fieldset are shown in the following diagram.
The fields of the RmiDevDelegateFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| share | 0 | Whether device memory Granule should be shared | RmiDevMemShared |
| 63:1 | Reserved | SBZ |
15.4.13 RmiDevMemShared type
The RmiDevMemShared enumeration represents whether device memory is shared.
The RmiDevMemShared enumeration is a concrete type.
The width of the RmiDevMemShared enumeration is 1 bits.
The values of the RmiDevMemShared enumeration are shown in the following table.
The RmiDevMemShared enumeration is used in the following types:
15.4.14 RmiEmulatedMmio type
The RmiEmulatedMmio enumeration represents whether the host has completed emulation for an Emulatable Abort.
The RmiEmulatedMmio enumeration is a concrete type.
The width of the RmiEmulatedMmio enumeration is 1 bits.
The values of the RmiEmulatedMmio enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_NOT_EMULATED_MMIO | Host has not completed emulation for an Emulatable Abort. |
| 1 | RMI_EMULATED_MMIO | Host has completed emulation for an Emulatable Abort. |
The RmiEmulatedMmio enumeration is used in the following types:
15.4.15 RmiFeature type
The RmiFeature enumeration represents whether a feature is supported or enabled.
The RmiFeature enumeration is a concrete type.
The width of the RmiFeature enumeration is 1 bits.
The values of the RmiFeature enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_FEATURE_FALSE |
|
| 1 | RMI_FEATURE_TRUE |
|
The RmiFeature enumeration is used in the following types:
15.4.16 RmiFeatureRegister0 type
The RmiFeatureRegister0 fieldset contains RMI feature register 0.
The RmiFeatureRegister0 fieldset is a concrete type.
The width of the RmiFeatureRegister0 fieldset is 64 bits.
The fields of the RmiFeatureRegister0 fieldset are shown in the following diagram.
The fields of the RmiFeatureRegister0 fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| S2SZ | 7:0 | Maximum Realm IPA width supported by the RMM. Specifies the input address size for stage 2 translation to be
|
UInt8 |
| LPA2 | 8 | Whether LPA2 is supported. | RmiFeature |
| SVE | 9 | Whether SVE is supported. | RmiFeature |
| SVE_VL | 13:10 | Maximum SVE vector length supported by the RMM. The effective vector length supported by the RMM is
|
UInt4 |
| NUM_BPS | 19:14 | Number of breakpoints available, minus one. The value 0 is reserved. |
UInt6 |
| NUM_WPS | 25:20 | Number of watchpoints available, minus one. The value 0 is reserved. |
UInt6 |
| PMU | 26 | Whether PMU is supported | RmiFeature |
| PMU_NUM_CTRS | 31:27 | Number of PMU counters available | UInt5 |
| HASH_SHA_256 | 32 | Whether SHA-256 is supported | RmiFeature |
| HASH_SHA_512 | 33 | Whether SHA-512 is supported | RmiFeature |
| GICV3_NUM_LRS | 37:34 | Number of GICv3 List Registers which are available, minus one. | UInt4 |
| MAX_RECS_ORDER | 41:38 | Order of the maximum number of RECs which can be created per Realm. The maximum number of RECs is computed as follows:
|
UInt4 |
| DA | 42 | Whether Realm device assignment is supported | RmiFeature |
| PLANE_RTT | 44:43 | RTT usage models supported for multi-Plane Realms. If only a single Plane is supported (that is, MAX_NUM_AUX_PLANES is 0), this field can be ignored. |
RmiPlaneRttFeature |
| MAX_NUM_AUX_PLANES | 48:45 | Maximum number of auxiliary Planes | UInt4 |
| 63:49 | Reserved | MBZ |
15.4.17 RmiFeatureRegister1 type
The RmiFeatureRegister1 fieldset contains RMI feature register 1.
The RmiFeatureRegister1 fieldset is a concrete type.
The width of the RmiFeatureRegister1 fieldset is 64 bits.
The fields of the RmiFeatureRegister1 fieldset are shown in the following diagram.
The fields of the RmiFeatureRegister1 fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| MAX_MECID | 63:0 | Maximum MECID. | Bits64 |
15.4.18 RmiHashAlgorithm type
The RmiHashAlgorithm enumeration represents hash algorithm.
The RmiHashAlgorithm enumeration is a concrete type.
The width of the RmiHashAlgorithm enumeration is 8 bits.
The values of the RmiHashAlgorithm enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_HASH_SHA_256 | SHA-256 (Secure Hash Standard (SHS) [19]) |
| 1 | RMI_HASH_SHA_512 | SHA-512 (Secure Hash Standard (SHS) [19]) |
Unused encodings for the RmiHashAlgorithm enumeration are reserved for use by future versions of this specification.
The RmiHashAlgorithm enumeration is used in the following types:
15.4.19 RmiInjectSea type
The RmiInjectSea enumeration represents whether to inject a Synchronous External Abort into the Realm.
The RmiInjectSea enumeration is a concrete type.
The width of the RmiInjectSea enumeration is 1 bits.
The values of the RmiInjectSea enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_NO_INJECT_SEA | Do not inject an SEA into the Realm. |
| 1 | RMI_INJECT_SEA | Inject an SEA into the Realm. |
The RmiInjectSea enumeration is used in the following types:
15.4.20 RmiInterfaceVersion type
The RmiInterfaceVersion fieldset contains an RMI interface version.
The RmiInterfaceVersion fieldset is a concrete type.
The width of the RmiInterfaceVersion fieldset is 64 bits.
The fields of the RmiInterfaceVersion fieldset are shown in the following diagram.
The fields of the RmiInterfaceVersion fieldset are shown in the following table.
15.4.21 RmiLfaPolicy type
The RmiLfaPolicy enumeration represents a Live Firmware Activation policy.
The RmiLfaPolicy enumeration is a concrete type.
The width of the RmiLfaPolicy enumeration is 2 bits.
See also:
- Section 3.12
The values of the RmiLfaPolicy enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_LFA_DISALLOW | LFA is not permitted. |
| 1 | RMI_LFA_ALLOW | LFA is permitted. |
Unused encodings for the RmiLfaPolicy enumeration are reserved for use by future versions of this specification.
The RmiLfaPolicy enumeration is used in the following types:
15.4.22 RmiPdevEvent type
The RmiPdevEvent enumeration represents physical device event.
The RmiPdevEvent enumeration is a concrete type.
The width of the RmiPdevEvent enumeration is 8 bits.
The values of the RmiPdevEvent enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_IDE_KEY_REFRESH | IDE key refresh. |
Unused encodings for the RmiPdevEvent enumeration are reserved for use by future versions of this specification.
15.4.23 RmiPdevFlags type
The RmiPdevFlags fieldset contains flags provided by the Host during PDEV creation.
The RmiPdevFlags fieldset is a concrete type.
The width of the RmiPdevFlags fieldset is 64 bits.
The fields of the RmiPdevFlags fieldset are shown in the following diagram.
The fields of the RmiPdevFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| prot_config | 3:21:0 | Configuration of protection between system and device | RmiPdevProtConfig |
| 63:563:2 | Reserved | SBZ |
The RmiPdevFlags fieldset is used in the following types:
15.4.24 RmiPdevIdeRmiPdevParams type
The RmiPdevIde enumeration represents whether the link to the device is protected using IDERmiPdevParams structure contains parameters provided by the Host during PDEV creation.
The RmiPdevIde enumerationRmiPdevParams structure is a concrete type.
The width of the RmiPdevIde enumeration is 1 bitsRmiPdevParams structure is 4096
(0x1000) bytes.
The values of the RmiPdevIde enumerationmembers of the RmiPdevParams structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| flags | 0x0 |
RmiPdevFlags | Flags |
| pdev_id | 0x8 |
Bits64 | Physical device identifier For a PCIe device this is the PCIe routing identifier of the endpoint. For function 0 of a PCIe device, pdev_id[11:0] MBZ. |
| RMI_IDE_FALSEsegment_id | The link to the0x10 |
Bits16 | Segment identifier PCIe Segment identifier of the Root Port and endpoint. |
| root_id | 0x18 |
Bits16 | Root Port identifier Physical PCIe routing identifier of the Root Port to which the endpoint is connected. |
| cert_id | 0x20 |
UInt64 | Certificate identifier |
| rid_base | 0x28 |
UInt64 | Base of requester ID range (inclusive) |
| rid_top | 0x30 |
UInt64 | Top of requester ID range (exclusive) |
| hash_algo | 0x38 |
RmiHashAlgorithm | Algorithm used to generate device is not protected using digests |
| num_aux | 0x40 |
UInt64 | Number of auxiliary Granules |
| ide_sid | 0x48 |
UInt64 | IDE stream ID |
| iocoh_num_addr_range | 0x50 |
UInt64 | Number of IO-coherent address ranges |
| fcoh_num_addr_range | 0x58 |
UInt64 | Number of fully-coherent address ranges. |
| aux[32] | 0x100 |
Address | Addresses of auxiliary Granules |
| 1iocoh_addr_range[16] | RMI_IDE_TRUE0x200 |
The link to the device is protected using IDERmiAddressRange | IO-coherent address range |
| fcoh_addr_range[4] | 0x300 |
RmiAddressRange | Fully-coherent address range |
Unused bits of the RmiPdevParams structure SBZ.
15.4.25 RmiPdevParamsRmiPdevProtConfig type
The RmiPdevParams structure contains parameters provided by the Host during PDEV creationRmiPdevProtConfig enumeration represents configuration of protection between system and device.
The RmiPdevParams structureRmiPdevProtConfig enumeration is a concrete type.
The width of the RmiPdevParams structure is 4096 (0x1000) bytesRmiPdevProtConfig enumeration is 2 bits.
The members of the RmiPdevParams structurevalues of the RmiPdevProtConfig enumeration are shown in the following table.
| Encoding | Name | Byte offset TypeDescription |
|---|---|---|
| flags0 | 0x0RMI_PDEV_IOCOH_E2E_IDE | IO-coherent device with end-to-end protection provided by IDE. |
| 1 | RMI_PDEV_IOCOH_E2E_SYS | IO-coherent device with end-to-end protection provided by system construction. |
| 2 | RMI_PDEV_FCOH_E2E_IDE | Fully-coherent device with end-to-end protection provided by IDE. |
| 3 | RMI_PDEV_FCOH_E2E_SYS | Fully-coherent device with end-to-end protection provided by system construction. |
The RmiPdevProtConfig enumeration is used in the following types:
- RmiPdevFlags Flags pdev_id 0x8 Bits64 Physical device identifier For a PCIe device this is the PCIe routing identifier of the endpoint. For function 0 of a PCIe device, pdev_id[11:0] MBZ. segment_id 0x10 Bits16 Segment identifier PCIe Segment identifier of the Root Port and endpoint. root_id 0x18 Bits16 Root Port identifier Physical PCIe routing identifier of the Root Port to which the endpoint is connected. cert_id 0x20 UInt64 Certificate identifier rid_base 0x28 UInt64 Base of requester ID range (inclusive) rid_top 0x30 UInt64 Top of requester ID range (exclusive) hash_algo 0x38 RmiHashAlgorithm Algorithm used to generate device digests num_aux 0x40 UInt64 Number of auxiliary Granules ncoh_sid 0x48 UInt64 IDE stream ID used to secure non-coherent traffic ncoh_num_addr_range 0x50 UInt64 Number of non-coherent address ranges coh_sid 0x58 UInt64 IDE stream ID used to secure coherent traffic coh_num_addr_range 0x60 UInt64 Number of coherent address ranges. aux[32] 0x100 Address Addresses of auxiliary Granules ncoh_addr_range[16] 0x200 RmiAddressRange Non-coherent address range coh_addr_range[4] 0x300 RmiAddressRange Coherent address range Unused bits of the RmiPdevParams structure SBZ.
15.4.26 RmiPdevProtConfigRmiPdevState type
The RmiPdevProtConfigRmiPdevState enumeration represents configuration of protection between system and devicethe state of a PDEV.
The RmiPdevProtConfigRmiPdevState enumeration is a concrete type.
The width of the RmiPdevProtConfigRmiPdevState enumeration is 28 bits.
The values of the RmiPdevProtConfigRmiPdevState enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_PDEV_NCOH_E2ERMI_PDEV_NEW | Non-coherentInitial state of the device with end-to-end protection. |
| 1 | RMI_PDEV_COH_LINKRMI_PDEV_NEEDS_KEY | CoherentRMM needs device with link protectionpublic key. |
| 2 | RMI_PDEV_COH_E2ERMI_PDEV_HAS_KEY | CoherentRMM has device with end-to-end protectionpublic key. |
| 3 | RMI_PDEV_READY | Secure connection between the RMM and the device has been established. Physical link between the device and memory is secured. Ready for creation of VDEV instances. |
| 4 | RMI_PDEV_COMMUNICATING | The RMM is communicating with the device. |
| 5 | RMI_PDEV_STOPPING | The RMM is communicating with the device to terminate the secure connection between the RMM and the device. |
| 6 | RMI_PDEV_STOPPED | Secure connection between the RMM and the device has been terminated. |
| 7 | RMI_PDEV_ERROR | Device has reported a fatal error. |
Unused encodings for the RmiPdevProtConfigRmiPdevState enumeration are reserved for use by future versions of this specification.
15.4.27 RmiPdevSpdm RmiPlaneRttFeature type
The RmiPdevSpdmRmiPlaneRttFeature enumeration represents whether communication between the RMM and the device uses SPDMRTT usage models supported for multi-Plane Realms.
The RmiPdevSpdmRmiPlaneRttFeature enumeration is a concrete type.
The width of the RmiPdevSpdmRmiPlaneRttFeature enumeration is 12 bits.
The values of the RmiPdevSpdm enumeration are shown in the following table. Encoding Name Description 0 RMI_SPDM_FALSE Communication between the RMM and the device does not use SPDM. 1 RMI_SPDM_TRUE Communication between the RMM and the device uses SPDM. 15.4.28 RmiPdevState type The RmiPdevState enumeration represents the state of a PDEV. The RmiPdevState enumeration is a concrete type. The width of the RmiPdevState enumeration is 8 bits. The values of the RmiPdevState enumeration are shown in the following table. Encoding Name Description 0 RMI_PDEV_NEW Initial state of the device. 1 RMI_PDEV_NEEDS_KEY RMM needs device public key. 2 RMI_PDEV_HAS_KEY RMM has device public key. 3 RMI_PDEV_READY Secure connection between the RMM and the device has been established. Physical link between the device and memory is secured. Ready for creation of VDEV instances. 4 RMI_PDEV_COMMUNICATING The RMM is communicating with the device. 5 RMI_PDEV_STOPPING The RMM is communicating with the device to terminate the secure connection between the RMM and the device. 6 RMI_PDEV_STOPPED Secure connection between the RMM and the device has been terminated. 7 RMI_PDEV_ERROR Device has reported a fatal error. Unused encodings for the RmiPdevState enumeration are reserved for use by future versions of this specification. 15.4.29 RmiPlaneRttFeature type The RmiPlaneRttFeature enumeration represents RTT usage models supported for multi-Plane Realms. The RmiPlaneRttFeature enumeration is a concrete type. The width of the RmiPlaneRttFeature enumeration is 2 bits.See also:
- Section 3.11
The values of the RmiPlaneRttFeature enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_PLANE_RTT_AUX | A multi-Plane Realm uses auxiliary RTTs |
| 1 | RMI_PLANE_RTT_AUX_SINGLE | A multi-Plane Realm can be configured to either use auxiliary RTTs, or a single RTT |
| 2 | RMI_PLANE_RTT_SINGLE | A multi-Plane Realm uses a single RTT |
Unused encodings for the RmiPlaneRttFeature enumeration are reserved for use by future versions of this specification.
The RmiPlaneRttFeature enumeration is used in the following types:
15.4.28 RmiPmuOverflowStatus type
The RmiPmuOverflowStatus enumeration represents PMU overflow status.
The RmiPmuOverflowStatus enumeration is a concrete type.
The width of the RmiPmuOverflowStatus enumeration is 8 bits.
The values of the RmiPmuOverflowStatus enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_PMU_OVERFLOW_NOT_ACTIVE | PMU overflow is not active. |
| 1 | RMI_PMU_OVERFLOW_ACTIVE | PMU overflow is active. |
Unused encodings for the RmiPmuOverflowStatus enumeration are reserved for use by future versions of this specification.
The RmiPmuOverflowStatus enumeration is used in the following types:
15.4.29 RmiRealmFlags0 type
The RmiRealmFlags0 fieldset contains flags provided by the Host during Realm creation, which are reflected in Realm Initial Measurement.
The RmiRealmFlags0 fieldset is a concrete type.
The width of the RmiRealmFlags0 fieldset is 64 bits.
The fields of the RmiRealmFlags0 fieldset are shown in the following diagram.
The fields of the RmiRealmFlags0 fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| lpa2 | 0 | Whether LPA2 is enabled | RmiFeature |
| sve | 1 | Whether SVE is enabled | RmiFeature |
| pmu | 2 | Whether PMU is enabled | RmiFeature |
| da | 3 | Whether Realm device assignment is enabled | RmiFeature |
| 4 | Reserved | SBZ | |
| lfa_policy | 6:5 | Live Firmware Activation policy for components within the Realm’s TCB | RmiLfaPolicy |
| 63:7 | Reserved | SBZ |
The RmiRealmFlags0 fieldset is used in the following types:
15.4.30 RmiPmuOverflowStatus RmiRealmFlags1 type
The RmiPmuOverflowStatus enumeration represents PMU overflow statusRmiRealmFlags1 fieldset contains flags provided by the Host during Realm creation, which are not reflected in Realm Initial Measurement.
The RmiPmuOverflowStatus enumerationRmiRealmFlags1 fieldset is a concrete type.
The width of the RmiPmuOverflowStatus enumeration is 8RmiRealmFlags1 fieldset is 64 bits.
The values of the RmiPmuOverflowStatus enumerationfields of the RmiRealmFlags1 fieldset are shown in the following diagram.
The fields of the RmiRealmFlags1 fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| rtt_tree_pp | 0 | RMI_PMU_OVERFLOW_NOT_ACTIVE RMI_FEATURE_FALSE: all Planes share a single RTT tree RMI_FEATURE_TRUE: each Plane has a separate RTT tree |
PMU overflow is not active.RmiFeature |
| 1 | RMI_PMU_OVERFLOW_ACTIVE63:1 | PMU overflow is active.Reserved | SBZ |
Unused encodings for the RmiPmuOverflowStatus enumeration are reserved for use by future versions of this specification.The RmiRealmFlags1 fieldset is used in the following types:
15.4.31 RmiRealmFlags0RmiRealmParams type
The RmiRealmFlags0 fieldsetRmiRealmParams structure contains flagsparameters provided by the Host during Realm creation, which are reflected in Realm Initial Measurement.
The RmiRealmFlags0 fieldsetRmiRealmParams structure is a concrete type.
The width of the RmiRealmFlags0 fieldset is 64 bits.
The fields of the RmiRealmFlags0 fieldset are shown in the following
diagram.
The fields of the RmiRealmFlags0 fieldset are shown in the following
table.
Name
Bits
Description
Value
lpa2
0
Whether LPA2 is enabled
RmiFeature
sve
1
Whether SVE is enabled
RmiFeature
pmu
2
Whether PMU is enabled
RmiFeature
da
3
Whether Realm device assignment is enabled
RmiFeature
4
Reserved
SBZ
lfa_policy
6:5
Live Firmware Activation policy for components within the Realm’s
TCB
RmiLfaPolicy
63:7
Reserved
SBZ
15.4.32 RmiRealmFlags1 type
The RmiRealmFlags1 fieldset contains flags provided by the Host
during Realm creation, which are not reflected in Realm Initial
Measurement.
The RmiRealmFlags1 fieldset is a concrete type.
The width of the RmiRealmFlags1 fieldset is 64 bits.
The fields of the RmiRealmFlags1 fieldset are shown in the following
diagram.
The fields of the RmiRealmFlags1 fieldset are shown in the following
table.
Name
Bits
Description
Value
rtt_tree_pp
0
RMI_FEATURE_FALSE: all Planes share a single RTT tree
RMI_FEATURE_TRUE: each Plane has a separate RTT tree
RmiFeature
63:1
Reserved
SBZ
15.4.33 RmiRealmParams type
The RmiRealmParams structure contains parameters provided by the Host
during Realm creation.
The RmiRealmParams structure is a concrete type.
The width of the RmiRealmParams structure is 4096
(0x1000) bytes.
The members of the RmiRealmParams structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| flags0 | 0x0 |
RmiRealmFlags0 | Flags |
| s2sz | 0x8 |
UInt8 | IPA width. Specifies the input address size for stage 2 translation to be
|
| sve_vl | 0x10 |
UInt8 | SVE vector length. The effective vector length requested is
|
| num_bps | 0x18 |
UInt8 | Number of breakpoints, minus one. The value 0 is reserved. |
| num_wps | 0x20 |
UInt8 | Number of watchpoints, minus one. The value 0 is reserved. |
| pmu_num_ctrs | 0x28 |
UInt8 | Number of PMU counters |
| hash_algo | 0x30 |
RmiHashAlgorithm | Algorithm used to measure the initial state of the Realm |
| num_aux_planes | 0x38 |
UInt64 | Number of auxiliary Planes |
| rpv | 0x400 |
Bits512 | Realm Personalization Value |
| vmid | 0x800 |
Bits16 | Primary Virtual Machine Identifier |
| rtt_base | 0x808 |
Address | Base address of primary RTT |
| rtt_level_start | 0x810 |
Int64 | RTT starting level |
| rtt_num_start | 0x818 |
UInt32 | Number of starting level RTTs |
| flags1 | 0x820 |
RmiRealmFlags1 | Flags |
| mecid | 0x828 |
Bits64 | MECID |
| aux_vmid[3] | 0xf00 |
Bits16 | Auxiliary Virtual Machine Identifiers |
| aux_rtt_base[3] | 0xf80 |
Address | Base address of auxiliary RTTs |
Unused bits of the RmiRealmParams structure SBZ.
15.4.3432 RmiRecCreateFlags type
The RmiRecCreateFlags fieldset contains flags provided by the Host during REC creation.
The RmiRecCreateFlags fieldset is a concrete type.
The width of the RmiRecCreateFlags fieldset is 64 bits.
The fields of the RmiRecCreateFlags fieldset are shown in the following diagram.
The fields of the RmiRecCreateFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| runnable | 0 | Whether REC is eligible for execution | RmiRecRunnable |
| 63:1 | Reserved | SBZ |
The RmiRecCreateFlags fieldset is used in the following types:
15.4.3533 RmiRecEnter type
The RmiRecEnter structure contains data passed from the Host to the RMM on REC entry.
The RmiRecEnter structure is a concrete type.
The width of the RmiRecEnter structure is 2048 (0x800)
bytes.
The members of the RmiRecEnter structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| flags | 0x0 |
RmiRecEnterFlags | Flags |
| gprs[31] | 0x200 |
Bits64 | Registers |
| gicv3_hcr | 0x300 |
Bits64 | GICv3 Hypervisor Control Register value |
| gicv3_lrs[16] | 0x308 |
Bits64 | GICv3 List Register values |
Unused bits of the RmiRecEnter structure SBZ.
The RmiRecEnter structure is used in the following types:
15.4.3634 RmiRecEnterFlags type
The RmiRecEnterFlags fieldset contains flags provided by the Host during REC entry.
The RmiRecEnterFlags fieldset is a concrete type.
The width of the RmiRecEnterFlags fieldset is 64 bits.
The fields of the RmiRecEnterFlags fieldset are shown in the following diagram.
The fields of the RmiRecEnterFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| emul_mmio | 0 | Whether the host has completed emulation for an Emulatable Data Abort | RmiEmulatedMmio |
| inject_sea | 1 | Whether to inject a Synchronous External Abort into the Realm. | RmiInjectSea |
| trap_wfi | 2 | Whether to trap WFI execution by the Realm. | RmiTrap |
| trap_wfe | 3 | Whether to trap WFE execution by the Realm. | RmiTrap |
| ripas_response | 4 | Host response to RIPAS change request. | RmiResponse |
| s2ap_response | 5 | Host response to S2AP change request. | RmiResponse |
| 63:6 | Reserved | SBZ |
The RmiRecEnterFlags fieldset is used in the following types:
15.4.3735 RmiRecExit type
The RmiRecExit structure contains data passed from the RMM to the Host on REC exit.
The RmiRecExit structure is a concrete type.
The width of the RmiRecExit structure is 2048 (0x800)
bytes.
The members of the RmiRecExit structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| exit_reason | 0x0 |
RmiRecExitReason | Exit reason |
| flags | 0x8 |
RmiRecExitFlags | Flags |
| esr | 0x100 |
Bits64 | Exception Syndrome Register |
| far | 0x108 |
Bits64 | Fault Address Register |
| hpfar | 0x110 |
Bits64 | Hypervisor IPA Fault Address register |
| rtt_tree | 0x118 |
UInt64 | Index of RTT tree active at time of the exit |
| rtt_level | 0x120 |
Int64 | Level of requested RTT |
| gprs[31] | 0x200 |
Bits64 | Registers |
| gicv3_hcr | 0x300 |
Bits64 | GICv3 Hypervisor Control Register value |
| gicv3_lrs[16] | 0x308 |
Bits64 | GICv3 List Register values |
| gicv3_misr | 0x388 |
Bits64 | GICv3 Maintenance Interrupt State Register value |
| gicv3_vmcr | 0x390 |
Bits64 | GICv3 Virtual Machine Control Register value |
| cntp_ctl | 0x400 |
Bits64 | Counter-timer Physical Timer Control Register value |
| cntp_cval | 0x408 |
Bits64 | Counter-timer Physical Timer CompareValue Register value |
| cntv_ctl | 0x410 |
Bits64 | Counter-timer Virtual Timer Control Register value |
| cntv_cval | 0x418 |
Bits64 | Counter-timer Virtual Timer CompareValue Register value |
| ripas_base | 0x500 |
Bits64 | Base address of target region for pending RIPAS change |
| ripas_top | 0x508 |
Bits64 | Top address of target region for pending RIPAS change |
| ripas_value | 0x510 |
RmiRipas | RIPAS value of pending RIPAS change |
| ripas_dev_pa | 0x518 |
Address | Base PA of device memory region, if RIPAS change is pending due to exection of RSI_RDEV_VALIDATE_MAPPING |
| s2ap_base | 0x520 |
Bits64 | Base address of target region for pending S2AP change |
| s2ap_top | 0x528 |
Bits64 | Top address of target region for pending S2AP change |
| vdev_id | 0x530 |
Bits64 | Virtual device ID |
| imm | 0x600 |
Bits16 | Host call immediate value |
| plane | 0x608 |
UInt64 | Plane index |
| vdev | 0x610 |
Address | VDEV which triggered REC exit due to device communication |
| vdev_action | 0x618 |
RmiVdevAction | Action which triggered REC exit due to device communication |
| pmu_ovf_status | 0x700 |
RmiPmuOverflowStatus | PMU overflow status |
Unused bits of the RmiRecExit structure MBZ.
The RmiRecExit structure is used in the following types:
15.4.36 RmiRecExitFlags type
The RmiRecExitFlags fieldset contains flags provided by the RMM during REC exit.
The RmiRecExitFlags fieldset is a concrete type.
The width of the RmiRecExitFlags fieldset is 64 bits.
The fields of the RmiRecExitFlags fieldset are shown in the following diagram.
The fields of the RmiRecExitFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| ripas_dev_shared | 0 | Value of shared bit, if RIPAS change is pending due to exection of RSI_RDEV_VALIDATE_MAPPING | RmiDevMemShared |
| 63:1 | Reserved | MBZ |
The RmiRecExitFlags fieldset is used in the following types:
15.4.37 RmiRecExitReason type
The RmiRecExitReason enumeration represents the reason for a REC exit.
The RmiRecExitReason enumeration is a concrete type.
The width of the RmiRecExitReason enumeration is 8 bits.
The values of the RmiRecExitReason enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_EXIT_SYNC | REC exit due to synchronous exception |
| 1 | RMI_EXIT_IRQ | REC exit due to IRQ |
| 2 | RMI_EXIT_FIQ | REC exit due to FIQ |
| 3 | RMI_EXIT_PSCI | REC exit due to PSCI |
| 4 | RMI_EXIT_RIPAS_CHANGE | REC exit due to RIPAS change pending |
| 5 | RMI_EXIT_HOST_CALL | REC exit due to Host call |
| 6 | RMI_EXIT_SERROR | REC exit due to SError |
| 7 | RMI_EXIT_DEV_COMM | REC exit due to device communication |
| 8 | RMI_EXIT_RTT_REQUEST | REC exit due to RTT request |
| 9 | RMI_EXIT_S2AP_CHANGE | REC exit due to S2AP change pending |
| 10 | RMI_EXIT_VDEV_REQUEST | REC exit due to VDEV request |
Unused encodings for the RmiRecExitReason enumeration are reserved for use by future versions of this specification.
The RmiRecExitReason enumeration is used in the following types:
15.4.38 RmiRecExitFlagsRmiRecMpidr type
The RmiRecExitFlagsRmiRecMpidr fieldset contains flags provided by the RMM during MPIDR value which identifies a REC exit.
The RmiRecExitFlagsRmiRecMpidr fieldset is a concrete type.
The width of the RmiRecExitFlagsRmiRecMpidr fieldset is 64 bits.
The fields of the RmiRecExitFlags fieldset are shown in the following diagram. The fields of the RmiRecExitFlags fieldset are shown in the following table. Name Bits Description Value ripas_dev_shared 0 Value of shared bit, if RIPAS change is pending due to exection of RSI_RDEV_VALIDATE_MAPPING RmiDevMemShared 63:1 Reserved MBZ 15.4.39 RmiRecExitReason type The RmiRecExitReason enumeration represents the reason for a REC exit. The RmiRecExitReason enumeration is a concrete type. The width of the RmiRecExitReason enumeration is 8 bits. The values of the RmiRecExitReason enumeration are shown in the following table. Encoding Name Description 0 RMI_EXIT_SYNC REC exit due to synchronous exception 1 RMI_EXIT_IRQ REC exit due to IRQ 2 RMI_EXIT_FIQ REC exit due to FIQ 3 RMI_EXIT_PSCI REC exit due to PSCI 4 RMI_EXIT_RIPAS_CHANGE REC exit due to RIPAS change pending 5 RMI_EXIT_HOST_CALL REC exit due to Host call 6 RMI_EXIT_SERROR REC exit due to SError 7 RMI_EXIT_DEV_COMM REC exit due to device communication 8 RMI_EXIT_RTT_REQUEST REC exit due to RTT request 9 RMI_EXIT_S2AP_CHANGE REC exit due to S2AP change pending 10 RMI_EXIT_VDEV_REQUEST REC exit due to VDEV request Unused encodings for the RmiRecExitReason enumeration are reserved for use by future versions of this specification. 15.4.40 RmiRecMpidr type The RmiRecMpidr fieldset contains MPIDR value which identifies a REC. The RmiRecMpidr fieldset is a concrete type. The width of the RmiRecMpidr fieldset is 64 bits.The fields of the RmiRecMpidr fieldset are shown in the following diagram.
The fields of the RmiRecMpidr fieldset are shown in the following table.
The RmiRecMpidr fieldset is used in the following types:
15.4.4139 RmiRecParams type
The RmiRecParams structure contains parameters provided by the Host during REC creation.
The RmiRecParams structure is a concrete type.
The width of the RmiRecParams structure is 4096 (0x1000)
bytes.
The number of valid entries in the aux array is
determined by the return value from the RMI_REC_AUX_COUNT command.
See also:
- Section 15.3.27
The members of the RmiRecParams structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| flags | 0x0 |
RmiRecCreateFlags | Flags |
| mpidr | 0x100 |
RmiRecMpidr | MPIDR of the REC |
| pc | 0x200 |
Bits64 | Program counter |
| gprs[8] | 0x300 |
Bits64 | General-purpose registers |
| num_aux | 0x800 |
UInt64 | Number of auxiliary Granules |
| aux[16] | 0x808 |
Address | Addresses of auxiliary Granules |
Unused bits of the RmiRecParams structure SBZ.
15.4.4240 RmiRecRun type
The RmiRecRun structure contains fields used to share information between RMM and Host during REC entry and REC exit.
The RmiRecRun structure is a concrete type.
The width of the RmiRecRun structure is 4096 (0x1000)
bytes.
The members of the RmiRecRun structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| enter | 0x0 |
RmiRecEnter | Entry information |
| exit | 0x800 |
RmiRecExit | Exit information |
15.4.41 RmiRecRunnable type
The RmiRecRunnable enumeration represents whether a REC is eligible for execution.
The RmiRecRunnable enumeration is a concrete type.
The width of the RmiRecRunnable enumeration is 1 bits.
The values of the RmiRecRunnable enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_NOT_RUNNABLE | Not eligible for execution. |
| 1 | RMI_RUNNABLE | Eligible for execution. |
The RmiRecRunnable enumeration is used in the following types:
15.4.42 RmiResponse type
The RmiResponse enumeration represents whether the Host accepted or rejected a Realm request.
The RmiResponse enumeration is a concrete type.
The width of the RmiResponse enumeration is 1 bits.
The values of the RmiResponse enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_ACCEPT | Host accepted the Realm request. |
| 1 | RMI_REJECT | Host rejected the Realm request. |
The RmiResponse enumeration is used in the following types:
15.4.43 RmiRecRunnableRmiRipas type
The RmiRecRunnableRmiRipas enumeration represents whether a REC is eligible for executionrealm IPA state.
The RmiRecRunnableRmiRipas enumeration is a concrete type.
The width of the RmiRecRunnableRmiRipas enumeration is 18 bits.
The values of the RmiRecRunnableRmiRipas enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_NOT_RUNNABLERMI_EMPTY | Not eligible for executionAddress where no Realm resources are mapped. |
| 1 | RMI_RUNNABLERMI_RAM | Eligible for executionAddress where private code or data owned by the Realm is mapped. |
| 2 | RMI_DESTROYED | Address which is inaccessible to the Realm due to an action taken by the Host. |
| 3 | RMI_DEV | Address where memory of an assigned Realm device is mapped. |
Unused encodings for the RmiRipas enumeration are reserved for use by future versions of this specification.
The RmiRipas enumeration is used in the following types:
15.4.44 RmiResponseRmiRttEntryState type
The RmiResponseRmiRttEntryState enumeration represents whether the Host accepted or rejected a Realm requestthe state of an RTTE.
The RmiResponseRmiRttEntryState enumeration is a concrete type.
The width of the RmiResponseRmiRttEntryState enumeration is 18 bits.
The values of the RmiResponseRmiRttEntryState enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_ACCEPTRMI_UNASSIGNED | Host accepted the Realm requestThis RTTE is not associated with any Granule. |
| 1 | RMI_REJECTRMI_ASSIGNED | Host rejected the Realm request The output address of this RTTE points to:
|
| 2 | RMI_TABLE | The output address of this RTTE points to the next-level RTT. |
| 3 | RMI_ASSIGNED_DEV_PRIVATE | The output address of this RTTE points to an DEV_PRIVATE Granule. |
| 4 | RMI_ASSIGNED_DEV_SHARED | The output address of this RTTE points to an DEV_SHARED Granule. |
| 5 | RMI_AUX_DESTROYED | An auxiliary RTT was destroyed. |
Unused encodings for the RmiRttEntryState enumeration are reserved for use by future versions of this specification.
15.4.45 RmiRipas RmiSignatureAlgorithm type
The RmiRipasRmiSignatureAlgorithm enumeration represents realm IPA statesignature algorithm.
The RmiRipasRmiSignatureAlgorithm enumeration is a concrete type.
The width of the RmiRipasRmiSignatureAlgorithm enumeration is 8 bits.
The values of the RmiRipasRmiSignatureAlgorithm enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_EMPTYRMI_SIG_RSASSA_3072 | Address where no Realm resources are mappedSSA-3072 (RSA Cryptography Specifications Version 2.2 [20]) |
| 1 | RMI_RAMRMI_SIG_ECDSA_P256 | Address where private code or data owned by the Realm is mapped.ECDSA-P256 (Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) [21]) |
| 2 | RMI_DESTROYEDRMI_SIG_ECDSA_P384 | Address which is inaccessible to the Realm due to an action taken by the Host.ECDSA-P384 (Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) [21]) |
Unused encodings for the RmiRipasRmiSignatureAlgorithm enumeration are reserved for use by future versions of this specification.
15.4.46 RmiRttEntryStateRmiStatusCode type
The RmiRttEntryStateRmiStatusCode enumeration represents the state of an RTTEstatus of an RMI operation.
The RmiRttEntryStateRmiStatusCode enumeration is a concrete type.
The width of the RmiRttEntryStateRmiStatusCode enumeration is 8 bits.
The values of the RmiRttEntryState enumeration are shown in the following table. Encoding Name Description 0 RMI_UNASSIGNED This RTTE is not associated with any Granule. 1 RMI_ASSIGNED The output address of this RTTE points to: a DATA Granule, if the input address is a Protected IPA, or an NS Granule, if the input address is an Unprotected IPA. 2 RMI_TABLE The output address of this RTTE points to the next-level RTT. 3 RMI_ASSIGNED_DEV_PRIVATE The output address of this RTTE points to an DEV_PRIVATE Granule. 4 RMI_ASSIGNED_DEV_SHARED The output address of this RTTE points to an DEV_SHARED Granule. 5 RMI_AUX_DESTROYED An auxiliary RTT was destroyed. Unused encodings for the RmiRttEntryState enumeration are reserved for use by future versions of this specification. 15.4.47 RmiSignatureAlgorithm type The RmiSignatureAlgorithm enumeration represents signature algorithm. The RmiSignatureAlgorithm enumeration is a concrete type. The width of the RmiSignatureAlgorithm enumeration is 8 bits. The values of the RmiSignatureAlgorithm enumeration are shown in the following table. Encoding Name Description 0 RMI_SIG_RSASSA_3072 SSA-3072 (RSA Cryptography Specifications Version 2.2 [20]) 1 RMI_SIG_ECDSA_P256 ECDSA-P256 (Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) [21]) 2 RMI_SIG_ECDSA_P384 ECDSA-P384 (Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) [21]) Unused encodings for the RmiSignatureAlgorithm enumeration are reserved for use by future versions of this specification. 15.4.48 RmiStatusCode type The RmiStatusCode enumeration represents the status of an RMI operation. The RmiStatusCode enumeration is a concrete type. The width of the RmiStatusCode enumeration is 8 bits.The values of the RmiStatusCode enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_SUCCESS | Command completed successfully |
| 1 | RMI_ERROR_INPUT | The value of a command input value caused the command to fail |
| 2 | RMI_ERROR_REALM | An attribute of a Realm does not match the expected value |
| 3 | RMI_ERROR_REC | An attribute of a REC does not match the expected value |
| 4 | RMI_ERROR_RTT | An RTT walk terminated before reaching the target RTT level, or reached an RTTE with an unexpected value |
| 5 | RMI_ERROR_NOT_SUPPORTED | The command is not supported |
| 6 | RMI_ERROR_DEVICE | An attribute of a device does not match the expected value |
| 7 | RMI_ERROR_RTT_AUX | RTTE in an auxiliary RTT contained an unexpected value |
Unused encodings for the RmiStatusCode enumeration are reserved for use by future versions of this specification.
The RmiStatusCode enumeration is used in the following types:
15.4.47 RmiTrap type
The RmiTrap enumeration represents whether a trap is enabled.
The RmiTrap enumeration is a concrete type.
The width of the RmiTrap enumeration is 1 bits.
The values of the RmiTrap enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_NO_TRAP | Trap is disabled. |
| 1 | RMI_TRAP | Trap is enabled. |
The RmiTrap enumeration is used in the following types:
15.4.48 RmiUnprotectedS2AP type
The RmiUnprotectedS2AP enumeration represents mapping from Stage 2 base permission index to Stage 2 base permission value for an Unprotected IPA.
The RmiUnprotectedS2AP enumeration is a concrete type.
The width of the RmiUnprotectedS2AP enumeration is 4 bits.
The values of the RmiUnprotectedS2AP enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_UNPROTECTED_S2AP_NO_ACCESS | No access |
| 1 | RMI_UNPROTECTED_S2AP_RO | Read only |
| 2 | RMI_UNPROTECTED_S2AP_WO | Write only |
| 3 | RMI_UNPROTECTED_S2AP_RW | Read write |
Unused encodings for the RmiUnprotectedS2AP enumeration are reserved for use by future versions of this specification.
15.4.49 RmiTrapRmiVdevAction type
The RmiTrapRmiVdevAction enumeration represents whether a trap is enabledrealm action which triggered REC exit due to device communication.
The RmiTrapRmiVdevAction enumeration is a concrete type.
The width of the RmiTrapRmiVdevAction enumeration is 18 bits.
The values of the RmiTrapRmiVdevAction enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RMI_NO_TRAPRMI_VDEV_ACTION_GET_INTERFACE_REPORT | Trap is disabled.Exit triggered by RSI_RDEV_GET_INTERFACE_REPORT |
| 1 | RMI_TRAPRMI_VDEV_ACTION_GET_MEASUREMENTS | Trap is enabledExit triggered by RSI_RDEV_GET_MEASUREMENTS |
| 2 | RMI_VDEV_ACTION_LOCK | Exit triggered by RSI_RDEV_LOCK |
| 3 | RMI_VDEV_ACTION_START | Exit triggered by RSI_RDEV_START |
| 4 | RMI_VDEV_ACTION_STOP | Exit triggered by RSI_RDEV_STOP |
Unused encodings for the RmiVdevAction enumeration are reserved for use by future versions of this specification.
The RmiVdevAction enumeration is used in the following types:
15.4.50 RmiUnprotectedS2AP RmiVdevFlags type
The RmiUnprotectedS2AP enumeration represents mapping from Stage 2 base permission index to Stage 2 base permission value for an Unprotected IPARmiVdevFlags fieldset contains flags provided by the Host during VDEV creation.
The RmiUnprotectedS2AP enumerationRmiVdevFlags fieldset is a concrete type.
The width of the RmiUnprotectedS2AP enumeration is 4RmiVdevFlags fieldset is 64 bits.
The values of the RmiUnprotectedS2AP enumerationfields of the RmiVdevFlags fieldset are shown in the following diagram.
The fields of the RmiVdevFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| 0 | RMI_UNPROTECTED_S2AP_NO_ACCESS63:0 | No accessReserved | SBZ |
Unused encodings for the RmiUnprotectedS2AP enumeration are reserved for use by future versions of this specification.The RmiVdevFlags fieldset is used in the following types:
15.4.51 RmiVdevActionRmiVdevParams type
The RmiVdevAction enumeration represents realm action which triggered REC exit due to device communicationRmiVdevParams structure contains parameters provided by the Host during VDEV creation.
The RmiVdevAction enumerationRmiVdevParams structure is a concrete type.
The width of the RmiVdevAction enumeration is 8 bitsRmiVdevParams structure is 4096
(0x1000) bytes.
The values of the RmiVdevAction enumerationmembers of the RmiVdevParams structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| 0flags | RMI_VDEV_ACTION_GET_INTERFACE_REPORT0x0 |
Exit triggered by RSI_RDEV_GET_INTERFACE_REPORTRmiVdevFlags | Flags |
| 1vdev_id | RMI_VDEV_ACTION_GET_MEASUREMENTS0x8 |
Exit triggered by RSI_RDEV_GET_MEASUREMENTSBits64 | Virtual device identifier For a PCIe device this is the PCIe routing identifier of the virtual endpoint. |
| 2tdi_id | RMI_VDEV_ACTION_LOCK0x10 |
Exit triggered by RSI_RDEV_LOCKBits64 | TDI identifier |
| 3num_aux | RMI_VDEV_ACTION_START0x18 |
Exit triggered by RSI_RDEV_STARTUInt64 | Number of auxiliary Granules |
| 4aux[32] | RMI_VDEV_ACTION_STOP0x100 |
Exit triggered by RSI_RDEV_STOPAddress | Addresses of auxiliary Granules |
Unused encodings for the RmiVdevAction enumeration are reserved for use by future versions of this specificationbits of the RmiVdevParams structure SBZ.
15.4.52 RmiVdevFlagsRmiVdevState type
The RmiVdevFlags fieldset contains flags provided by the Host during RmiVdevState enumeration represents the state of a VDEV creation.
The RmiVdevFlags fieldsetRmiVdevState enumeration is a concrete type.
The width of the RmiVdevFlags fieldset is 64RmiVdevState enumeration is 8 bits.
The fields of the RmiVdevFlags fieldsetvalues of the RmiVdevState enumeration are shown in the following diagram. The fields of the RmiVdevFlags fieldset are shown in the following table.
| Encoding | Name | BitsDescription | Value
|---|---|---|
| 0 | RMI_VDEV_READY | No device transaction is associated with the VDEV. |
| 1 | RMI_VDEV_COMMUNICATING | The RMM is communicating with the VDEV. |
| 2 | RMI_VDEV_STOPPING | The RMM is communicating with the VDEV to stop the device interface. |
| 3 | RMI_VDEV_STOPPED | Device interface is stopped. |
| 4 | RMI_VDEV_ERROR | Device interface has reported a fatal error. |
Unused encodings for the RmiVdevState enumeration are reserved for use by future versions of this specification.
16 Realm Services Interface
This chapter defines the interface used by Realm software to request services from the RMM.
16.1 RSI version
This specification defines version 1.1 of the Realm Services Interface.
16.2 RSI command return codes
An RSI command return code indicates whether the command
- succeeded, or
- failed, and the reason for the failure.
If an RSI command succeeds then it returns RSI_SUCCESS.
Multiple failure conditions in an RSI command may return the same return code.
If an input to an RSI command uses an invalid encoding in an enumeration Invalid encodings include:then the command fails and returns RSI_ERROR_INPUT.
Command inputs include registers and in-memory data structures.
If an input to an RSI command uses an invalidInvalid encodings include:
- using a reserved encoding then the command fails and returns RSI_ERROR_INPUT.in an enumeration
See also:
- Section 16.4.2
16.3 RSI commands
The following table summarizes the FIDs of commands in the RSI interface.
| FID | Command |
|---|---|
0xC4000190 |
RSI_VERSION |
0xC4000191 |
RSI_FEATURES |
0xC4000192 |
RSI_MEASUREMENT_READ |
0xC4000193 |
RSI_MEASUREMENT_EXTEND |
0xC4000194 |
RSI_ATTESTATION_TOKEN_INIT |
0xC4000195 |
RSI_ATTESTATION_TOKEN_CONTINUE |
| … | |
0xC4000197 |
RSI_IPA_STATE_SET |
0xC4000198 |
RSI_IPA_STATE_GET |
0xC4000199 |
RSI_HOST_CALL |
| … | |
0xC40001A0 |
RSI_MEM_GET_PERM_VALUE |
0xC40001A1 |
RSI_MEM_SET_PERM_INDEX |
0xC40001A2 |
RSI_MEM_SET_PERM_VALUE |
0xC40001A3 |
RSI_PLANE_ENTER |
0xC40001A4 |
RSI_RDEV_CONTINUE |
0xC40001A5 |
RSI_RDEV_GET_INFO |
0xC40001A6 |
RSI_RDEV_GET_INTERFACE_REPORT |
0xC40001A7 |
RSI_RDEV_GET_MEASUREMENTS |
0xC40001A8 |
RSI_RDEV_GET_STATE |
0xC40001A9 |
RSI_RDEV_LOCK |
0xC40001AA |
RSI_RDEV_START |
0xC40001AB |
RSI_RDEV_STOP |
0xC40001AC |
RSI_RDEV_VALIDATE_MAPPING |
0xC40001AD |
RSI_REALM_CONFIG |
0xC40001AE |
RSI_PLANE_REG_READ |
0xC40001AF |
RSI_PLANE_REG_WRITE |
16.3.1 RSI_ATTESTATION_TOKEN_CONTINUE command
Continue the operation to retrieve an attestation token.
16.3.1.1 Interface
16.3.1.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000195 |
| addr | X1 | 63:0 | Address | IPA of the Granule to which the token will be written |
| offset | X2 | 63:0 | UInt64 | Offset within Granule to start of buffer in bytes |
| size | X3 | 63:0 | UInt64 | Size of buffer in bytes |
16.3.1.1.2 Context
The RSI_ATTESTATION_TOKEN_CONTINUE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rec | RmmRec | CurrentRec() |
false | Current REC |
16.3.1.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| len | X1 | 63:0 | UInt64 | Number of bytes written to buffer |
16.3.1.2 Failure conditions
| ID | Condition |
|---|---|
| addr_align | pre: !AddrIsGranuleAligned(addr) post: result == RSI_ERROR_INPUT |
| addr_bound | pre: !AddrIsProtected(addr, realm) post: result == RSI_ERROR_INPUT |
| offset_bound | pre: offset >= RMM_GRANULE_SIZE post: result == RSI_ERROR_INPUT |
| size_overflow | pre: offset + size < offset post: result == RSI_ERROR_INPUT |
| size_bound | pre: offset + size > RMM_GRANULE_SIZE post: result == RSI_ERROR_INPUT |
| state | pre: rec.attest_state != ATTEST_IN_PROGRESS post: result == RSI_ERROR_STATE |
| unknown | pre: Token generation failed for an unknown or IMPDEF reason. post: result == RSI_ERROR_UNKNOWN |
16.3.1.2.1 Failure condition ordering
The RSI_ATTESTATION_TOKEN_CONTINUE command does not have any failure condition orderings.
16.3.1.3 Success conditions
| ID | Condition |
|---|---|
| incomplete | pre: Token generation is not complete. post: result == RSI_INCOMPLETE |
| complete | pre: Token generation is complete. post: rec.attest_state == NO_ATTEST_IN_PROGRESS |
16.3.1.4 Footprint
| ID | Value |
|---|---|
| state | rec.attest_state |
16.3.2 RSI_ATTESTATION_TOKEN_INIT command
Initialize the operation to retrieve an attestation token.
16.3.2.1 Interface
16.3.2.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000194 |
| challenge_0 | X1 | 63:0 | Bits64 | Doubleword 0 of the challenge value |
| challenge_1 | X2 | 63:0 | Bits64 | Doubleword 1 of the challenge value |
| challenge_2 | X3 | 63:0 | Bits64 | Doubleword 2 of the challenge value |
| challenge_3 | X4 | 63:0 | Bits64 | Doubleword 3 of the challenge value |
| challenge_4 | X5 | 63:0 | Bits64 | Doubleword 4 of the challenge value |
| challenge_5 | X6 | 63:0 | Bits64 | Doubleword 5 of the challenge value |
| challenge_6 | X7 | 63:0 | Bits64 | Doubleword 6 of the challenge value |
| challenge_7 | X8 | 63:0 | Bits64 | Doubleword 7 of the challenge value |
16.3.2.1.2 Context
The RSI_ATTESTATION_TOKEN_INIT command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rec | RmmRec | CurrentRec() |
false | Current REC |
16.3.2.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| size | X1 | 63:0 | UInt64 | Upper bound on attestation token size in bytes |
16.3.2.2 Failure conditions
The RSI_ATTESTATION_TOKEN_INIT command does not have any failure conditions.
16.3.2.3 Success conditions
| ID | Condition |
|---|---|
| state | rec.attest_state == ATTEST_IN_PROGRESS |
| challenge |
rec.attest_challenge == [
challenge_0,
challenge_1,
challenge_2,
challenge_3,
challenge_4,
challenge_5,
challenge_6,
challenge_7
]
|
16.3.2.4 Footprint
| ID | Value |
|---|---|
| state | rec.attest_state |
| challenge | rec.attest_challenge |
16.3.3 RSI_FEATURES command
Read feature register.
The following table indicates which feature register is returned depending on the index provided.
| Index | Feature register |
|---|---|
| 0 | RSI feature register 0 |
See also:
- Section 3
16.3.3.1 Interface
16.3.3.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000191 |
| index | X1 | 63:0 | UInt64 | Feature register index |
16.3.3.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| value | X1 | 63:0 | Bits64 | Feature register value |
16.3.3.2 Failure conditions
The RSI_FEATURES command does not have any failure conditions.
16.3.3.3 Success conditions
| ID | Condition |
|---|---|
| value | value == RsiFeatureRegisterEncode(index) |
16.3.3.4 Footprint
The RSI_FEATURES command does not have any footprint.
16.3.4 RSI_HOST_CALL command
Make a Host call.
See also:
- Section 4.5
16.3.4.1 Interface
16.3.4.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000199 |
| addr | X1 | 63:0 | Address | IPA of the Host call data structure |
16.3.4.1.2 Context
The RSI_HOST_CALL command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rec | RmmRec | CurrentRec() |
false | Current REC |
| data | RsiHostCall | RsiHostCallAt(addr) |
false | Host call data structure |
16.3.4.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.4.2 Failure conditions
| ID | Condition |
|---|---|
| addr_align | pre: !AddrIsAligned(addr, 256) post: result == RSI_ERROR_INPUT |
| addr_bound | pre: !AddrIsProtected(addr, realm) post: result == RSI_ERROR_INPUT |
16.3.4.2.1 Failure condition ordering
The RSI_HOST_CALL command does not have any failure condition orderings.
16.3.4.3 Success conditions
The RSI_HOST_CALL command does not have any success conditions.
16.3.4.4 Footprint
| ID | Value |
|---|---|
| pending | rec.pending |
16.3.5 RSI_IPA_STATE_GET command
Get RIPAS of a target IPA range.
16.3.5.1 Interface
16.3.5.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000198 |
| base | X1 | 63:0 | Address | Base of target IPA region |
| top | X2 | 63:0 | Address | End of target IPA region |
16.3.5.1.2 Context
The RSI_IPA_STATE_GET command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
16.3.5.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| out_top | X1 | 63:0 | Address | Top of IPA region which has the reported RIPAS value |
| ripas | X2 | 7:0 | RsiRipas | RIPAS value |
The following unused bits of RSI_IPA_STATE_GET output values MBZ: X2[63:8].
If result == RSI_SUCCESS then all of the following are
true:
out_top > baseout_top <= top- All addresses within the range
[base, out_top)have the RIPAS valueripas.
Note that the RIPAS of a Protected IPA can change at any time to DESTROYED without the Realm taking any action.
See also:
- Section 5.2.5
16.3.5.2 Failure conditions
| ID | Condition |
|---|---|
| base_align | pre: !AddrIsGranuleAligned(base) post: result == RSI_ERROR_INPUT |
| end_align | pre: !AddrIsGranuleAligned(top) post: result == RSI_ERROR_INPUT |
| size_valid | pre: UInt(top) <= UInt(base) post: result == RSI_ERROR_INPUT |
| rgn_bound | pre: !AddrRangeIsProtected(base, top, realm) post: result == RSI_ERROR_INPUT |
16.3.5.2.1 Failure condition ordering
The RSI_IPA_STATE_GET command does not have any failure condition orderings.
16.3.5.3 Success conditions
The RSI_IPA_STATE_GET command does not have any success conditions.
16.3.5.4 Footprint
The RSI_IPA_STATE_GET command does not have any footprint.
16.3.6 RSI_IPA_STATE_SET command
Request RIPAS of a target IPA range to be changed to a specified value.
16.3.6.1 Interface
16.3.6.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000197 |
| base | X1 | 63:0 | Address | Base of target IPA region |
| top | X2 | 63:0 | Address | Top of target IPA region |
| ripas | X3 | 7:0 | RsiRipas | RIPAS value |
| flags | X4 | 63:0 | RsiRipasChangeFlags | Flags |
The following unused bits of RSI_IPA_STATE_SET input values SBZ: X3[63:8].
16.3.6.1.2 Context
The RSI_IPA_STATE_SET command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rec | RmmRec | CurrentRec() |
false | Current REC |
16.3.6.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| new_base | X1 | 63:0 | Address | Base of IPA region which was not modified by the command |
| response | X2 | 0:0 | RsiResponse | Whether the Host accepted or rejected the request |
The following unused bits of RSI_IPA_STATE_SET output values MBZ: X2[63:1].
If the Host rejects the request then:
result == RSI_SUCCESSnew_base == baseresponse == RSI_REJECT
16.3.6.2 Failure conditions
| ID | Condition |
|---|---|
| base_align | pre: !AddrIsGranuleAligned(base) post: result == RSI_ERROR_INPUT |
| top_align | pre: !AddrIsGranuleAligned(top) post: result == RSI_ERROR_INPUT |
| size_valid | pre: UInt(top) <= UInt(base) post: result == RSI_ERROR_INPUT |
| rgn_bound | pre: !AddrRangeIsProtected(base, top, realm) post: result == RSI_ERROR_INPUT |
| ripas_valid | pre: (ripas != RSI_EMPTY) && (ripas != RSI_RAM) post: result == RSI_ERROR_INPUT |
16.3.6.2.1 Failure condition ordering
The RSI_IPA_STATE_SET command does not have any failure condition orderings.
16.3.6.3 Success conditions
| ID | Condition |
|---|---|
| new_base | new_base == rec.ripas_addr |
| response | response == RecRipasResponseToRsi(rec) |
16.3.6.4 Footprint
The RSI_IPA_STATE_SET command does not have any footprint.
16.3.7 RSI_MEASUREMENT_EXTEND command
Extend Realm Extensible Measurement (REM) value.
16.3.7.1 Interface
16.3.7.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000193 |
| index | X1 | 63:0 | UInt64 | Measurement index |
| size | X2 | 63:0 | UInt64 | Measurement size in bytes |
| value_0 | X3 | 63:0 | Bits64 | Doubleword 0 of the measurement value |
| value_1 | X4 | 63:0 | Bits64 | Doubleword 1 of the measurement value |
| value_2 | X5 | 63:0 | Bits64 | Doubleword 2 of the measurement value |
| value_3 | X6 | 63:0 | Bits64 | Doubleword 3 of the measurement value |
| value_4 | X7 | 63:0 | Bits64 | Doubleword 4 of the measurement value |
| value_5 | X8 | 63:0 | Bits64 | Doubleword 5 of the measurement value |
| value_6 | X9 | 63:0 | Bits64 | Doubleword 6 of the measurement value |
| value_7 | X10 | 63:0 | Bits64 | Doubleword 7 of the measurement value |
16.3.7.1.2 Context
The RSI_MEASUREMENT_EXTEND command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| realm_pre | RmmRealm | CurrentRealm() |
true | Current Realm |
| meas_pre | RmmRealmMeasurement | CurrentRealm()realm_pre.measurements[index]measurements[ index] |
true | Previous measurement value |
16.3.7.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.7.2 Failure conditions
| ID | Condition |
|---|---|
| index_bound | pre: index < 1 || index > 4 post: result == RSI_ERROR_INPUT |
| size_bound | pre: size > 64 post: result == RSI_ERROR_INPUT |
16.3.7.2.1 Failure condition ordering
The RSI_MEASUREMENT_EXTEND command does not have any failure condition orderings.
16.3.7.3 Success conditions
| ID | Condition |
|---|---|
| realm_meas | realm.measurements[index] == RemExtend( realm.hash_algo, meas_pre, [value_0, value_1, value_2, value_3, value_4, value_5, value_6, value_7][ (RMM_REALM_MEASUREMENT_WIDTH-1):0], size) |
16.3.7.4 Footprint
| ID | Value |
|---|---|
| realm_meas | realm.measurements[index] |
16.3.8 RSI_MEASUREMENT_READ command
Read measurement for the current Realm.
16.3.8.1 Interface
16.3.8.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000192 |
| index | X1 | 63:0 | UInt64 | Measurement index |
index 0 selects the RIM. An index of 1 or
greater selects the corresponding REM.
16.3.8.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| value_0 | X1 | 63:0 | Bits64 | Doubleword 0 of the Realm measurement identified by “index” |
| value_1 | X2 | 63:0 | Bits64 | Doubleword 1 of the Realm measurement identified by “index” |
| value_2 | X3 | 63:0 | Bits64 | Doubleword 2 of the Realm measurement identified by “index” |
| value_3 | X4 | 63:0 | Bits64 | Doubleword 3 of the Realm measurement identified by “index” |
| value_4 | X5 | 63:0 | Bits64 | Doubleword 4 of the Realm measurement identified by “index” |
| value_5 | X6 | 63:0 | Bits64 | Doubleword 5 of the Realm measurement identified by “index” |
| value_6 | X7 | 63:0 | Bits64 | Doubleword 6 of the Realm measurement identified by “index” |
| value_7 | X8 | 63:0 | Bits64 | Doubleword 7 of the Realm measurement identified by “index” |
If the size of the measurement value is smaller than 512 bits, the output values are padded with zeroes.
16.3.8.2 Failure conditions
| ID | Condition |
|---|---|
| index_bound | pre: index > 4 post: result == RSI_ERROR_INPUT |
16.3.8.3 Success conditions
The RSI_MEASUREMENT_READ command does not have any success conditions.
16.3.8.4 Footprint
The RSI_MEASUREMENT_READ command does not have any footprint.
16.3.9 RSI_MEM_GET_PERM_VALUE command
Get overlay permission value for a specified (plane index, overlay permission index) tuple.
See also:
- Section 10.3.2
16.3.9.1 Interface
16.3.9.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001A0 |
| plane_index | X1 | 63:0 | UInt64 | Plane index |
| perm_index | X2 | 63:0 | UInt64 | Permission index |
16.3.9.1.2 Context
The RSI_MEM_GET_PERM_VALUE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
16.3.9.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| value | X1 | 63:0 | Bits64 | Memory permission value |
16.3.9.2 Failure conditions
| ID | Condition |
|---|---|
| plane_bound | pre: plane_index > realm.num_aux_planes post: result == RSI_ERROR_INPUT |
| perm_bound |
pre: perm_index >=
RMM_NUM_PERM_OVERLAY_INDICES
post: result == RSI_ERROR_INPUT
|
16.3.9.2.1 Failure condition ordering
The RSI_MEM_GET_PERM_VALUE command does not have any failure condition orderings.
16.3.9.3 Success conditions
| ID | Condition |
|---|---|
| label | value == realm.overlay_perms[plane_index].values[perm_index] |
16.3.9.4 Footprint
The RSI_MEM_GET_PERM_VALUE command does not have any footprint.
16.3.10 RSI_MEM_SET_PERM_INDEX command
Set overlay permission index for a specified IPA range.
See also:
- Section 10.3.2
16.3.10.1 Interface
16.3.10.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001A1 |
| base | X1 | 63:0 | Address | Base of target IPA region |
| top | X2 | 63:0 | Address | Top of target IPA region |
| perm_index | X3 | 63:0 | UInt64 | Permission index |
| cookie | X4 | 63:0 | Bits64 | Cookie value |
16.3.10.1.2 Context
The RSI_MEM_SET_PERM_INDEX command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rec | RmmRec | CurrentRec() |
false | Current REC |
16.3.10.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| new_base | X1 | 63:0 | Address | Base of IPA region which was not modified by the command |
| response | X2 | 0:0 | RsiResponse | Whether the Host accepted or rejected the request |
| new_cookie | X3 | 63:0 | Bits64 | New cookie value |
The following unused bits of RSI_MEM_SET_PERM_INDEX output values MBZ: X2[63:1].
16.3.10.2 Failure conditions
| ID | Condition |
|---|---|
| base_align | pre: !AddrIsGranuleAligned(base) post: result == RSI_ERROR_INPUT |
| top_align | pre: !AddrIsGranuleAligned(top) post: result == RSI_ERROR_INPUT |
| size_valid | pre: UInt(top) <= UInt(base) post: result == RSI_ERROR_INPUT |
| rgn_bound | pre: !AddrRangeIsProtected(base, top, realm) post: result == RSI_ERROR_INPUT |
| perm_bound |
pre: perm_index >=
RMM_NUM_PERM_OVERLAY_INDICES
post: result == RSI_ERROR_INPUT
|
| cookie | pre: Cookie is invalid post: result == RSI_ERROR_INPUT |
16.3.10.2.1 Failure condition ordering
The RSI_MEM_SET_PERM_INDEX command does not have any failure condition orderings.
16.3.10.3 Success conditions
| ID | Condition |
|---|---|
| locked | realm.overlay_locked[perm_index] == MEM_PERM_LOCKED |
| new_base | new_base == rec.s2ap_addr |
| response | response == RecS2APResponseToRsi(rec) |
16.3.10.4 Footprint
The RSI_MEM_SET_PERM_INDEX command does not have any footprint.
16.3.11 RSI_MEM_SET_PERM_VALUE command
Set overlay permission value for a specified (plane index, overlay permission index) tuple.
See also:
- Section 10.3.2
16.3.11.1 Interface
16.3.11.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001A2 |
| plane_index | X1 | 63:0 | UInt64 | Plane index |
| perm_index | X2 | 63:0 | UInt64 | Permission index |
| value | X3 | 63:0 | Bits64 | Memory permission value |
16.3.11.1.2 Context
The RSI_MEM_SET_PERM_VALUE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
16.3.11.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.11.2 Failure conditions
| ID | Condition |
|---|---|
| plane_bound |
pre: (plane_index == 0
|| plane_index > realm.num_aux_planes)
post: result == RSI_ERROR_INPUT
|
| perm_bound |
pre: perm_index >=
RMM_NUM_PERM_OVERLAY_INDICES
post: result == RSI_ERROR_INPUT
|
| locked | pre: realm.overlay_locked[perm_index] == MEM_PERM_LOCKED post: result == RSI_ERROR_INPUT |
| supported | pre: !MemPermLabelSupported(value) post: result == RSI_ERROR_INPUT |
16.3.11.2.1 Failure condition ordering
The RSI_MEM_SET_PERM_VALUE command does not have any failure condition orderings.
16.3.11.3 Success conditions
| ID | Condition |
|---|---|
| label | realm.overlay_perms[plane_index].values[perm_index] == value |
16.3.11.4 Footprint
The RSI_MEM_SET_PERM_VALUE command does not have any footprint.
16.3.12 RSI_PLANE_ENTER command
Enter a Plane.
See also:
- Section 10.2
16.3.12.1 Interface
16.3.12.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001A3 |
| plane_idx | X1 | 63:0 | UInt64 | Index of target Plane |
| run_ptr | X2 | 63:0 | Address | IPA of PlaneRun object |
16.3.12.1.2 Context
The RSI_PLANE_ENTER command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| run | RsiPlaneRun | RsiPlaneRunAt( realm, run_ptr) |
false | PlaneRun object |
16.3.12.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.12.2 Failure conditions
| ID | Condition |
|---|---|
| idx_bound |
pre: (plane_idx == 0
|| plane_idx > realm.num_aux_planes)
post: result == RSI_ERROR_INPUT
|
| run_align | pre: !AddrIsGranuleAligned(run_ptr) post: result == RSI_ERROR_INPUT |
| run_bound | pre: !AddrIsProtected(run_ptr, realm) post: result == RSI_ERROR_INPUT |
16.3.12.2.1 Failure condition ordering
The RSI_PLANE_ENTER command does not have any failure condition orderings.
16.3.12.3 Success conditions
| ID | Condition |
|---|---|
| plane_exit | run.exit contains Plane exit syndrome information. |
16.3.12.4 Footprint
The RSI_PLANE_ENTER command does not have any footprint.
16.3.13 RSI_PLANE_REG_READ command
Read a Plane register.
See also:
- Section 10.2.6
16.3.13.1 Interface
16.3.13.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001AE |
| plane_idx | X1 | 63:0 | UInt64 | Index of target Plane |
| encoding | X2 | 63:0 | Bits64 | Encoding of target register |
The encoding value is an architecturally-defined system register encoding.
16.3.13.1.2 Context
The RSI_PLANE_REG_READ command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
16.3.13.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| value | X1 | 63:0 | Bits64 | Value of target register |
16.3.13.2 Failure conditions
| ID | Condition |
|---|---|
| idx_bound | pre: plane_idx > realm.num_aux_planes post: result == RSI_ERROR_INPUT |
| reg_valid | pre: !PlaneRegIsValid(realm, encoding) post: result == RSI_ERROR_INPUT |
16.3.13.2.1 Failure condition ordering
The RSI_PLANE_REG_READ command does not have any failure condition orderings.
16.3.13.3 Success conditions
| ID | Condition |
|---|---|
| value | value == PlaneRegValue(realm, plane_idx, encoding) |
16.3.13.4 Footprint
The RSI_PLANE_REG_READ command does not have any footprint.
16.3.14 RSI_PLANE_REG_WRITE command
Write a Plane register.
See also:
- Section 10.2.6
16.3.14.1 Interface
16.3.14.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001AF |
| plane_idx | X1 | 63:0 | UInt64 | Index of target Plane |
| encoding | X2 | 63:0 | Bits64 | Encoding of target register |
| value | X3 | 63:0 | Bits64 | Value to write to target register |
The encoding value is an architecturally-defined system register encoding.
16.3.14.1.2 Context
The RSI_PLANE_REG_WRITE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
16.3.14.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.14.2 Failure conditions
| ID | Condition |
|---|---|
| idx_bound | pre: plane_idx > realm.num_aux_planes post: result == RSI_ERROR_INPUT |
| reg_valid | pre: !PlaneRegIsValid(realm, encoding) post: result == RSI_ERROR_INPUT |
16.3.14.2.1 Failure condition ordering
The RSI_PLANE_REG_WRITE command does not have any failure condition orderings.
16.3.14.3 Success conditions
| ID | Condition |
|---|---|
| value | PlaneRegValue(realm, plane_idx, encoding) == value |
16.3.14.4 Footprint
The RSI_PLANE_REG_WRITE command does not have any footprint.
16.3.15 RSI_RDEV_CONTINUE command
Continue an interruptible Realm device operation.
See also:
- Section 9.5.1
16.3.15.1 Interface
16.3.15.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001A4 |
| vdev_id | X1 | 63:0 | Bits64 | Realm device identifier |
| inst_id | X2 | 63:0 | UInt64 | Device instance identifier |
16.3.15.1.2 Context
The RSI_RDEV_CONTINUE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rdev | RmmRdev | RdevFromIds( realm, vdev_id, inst_id) |
false | Realm device |
16.3.15.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.15.2 Failure conditions
| ID | Condition |
|---|---|
| da_en | pre: realm.feat_da != FEATURE_TRUE post: result == RSI_ERROR_STATE |
| vdev_id | pre: !RdevIdsAreValid(realm, vdev_id, inst_id) post: result == RSI_ERROR_INPUT |
| state | pre: (rdev.state != RDEV_NEW_BUSY && rdev.state != RDEV_LOCKED_BUSY && rdev.state != RDEV_STARTED_BUSY && rdev.state != RDEV_STOPPING) post: result == RSI_ERROR_INPUT |
16.3.15.2.1 Failure condition ordering
[da_en] < [vdev_id]
[vdev_id] < [state]
16.3.15.3 Success conditions
| ID | Condition |
|---|---|
| error | pre: (DeviceCommunicate(rdev) == DEV_COMM_ERROR && rdev.state != RDEV_STOPPING) post: rdev.state == RDEV_ERROR |
| new | pre: (DeviceCommunicate(rdev) == DEV_COMM_IDLE && rdev.state == RDEV_NEW_BUSY && rdev.operation != RDEV_OP_LOCK) post: rdev.state == RDEV_NEW |
| to_locked | pre: (DeviceCommunicate(rdev) == DEV_COMM_IDLE && rdev.state == RDEV_NEW_BUSY && rdev.operation == RDEV_OP_LOCK) post: rdev.state == RDEV_LOCKED |
| locked | pre: (DeviceCommunicate(rdev) == DEV_COMM_IDLE && rdev.state == RDEV_LOCKED_BUSY && rdev.operation != RDEV_OP_LOCK) post: rdev.state == RDEV_LOCKED |
| to_started | pre: (DeviceCommunicate(rdev) == DEV_COMM_IDLE && rdev.state == RDEV_LOCKED_BUSY && rdev.operation == RDEV_OP_START) post: rdev.state == RDEV_STARTED |
| started | pre: (DeviceCommunicate(rdev) == DEV_COMM_IDLE && rdev.state == RDEV_STARTED_BUSY) post: rdev.state == RDEV_STARTED |
| stopped | pre: (DeviceCommunicate(rdev) != DEV_COMM_ACTIVE && rdev.state == RDEV_STOPPING) post: rdev.state == RDEV_STOPPED |
16.3.15.4 Footprint
| ID | Value |
|---|---|
| state | rdev.state |
16.3.16 RSI_RDEV_GET_INFO command
Get information for a device.
16.3.16.1 Interface
16.3.16.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001A5 |
| vdev_id | X1 | 63:0 | Bits64 | Realm device identifier |
| addr | X2 | 63:0 | Address | IPA of the Granule to which the configuration data will be written |
16.3.16.1.2 Context
The RSI_RDEV_GET_INFO command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rdev | RmmRdev | RdevFromId(realm, vdev_id) |
false | Realm device |
| pdevvdev | RmmPdevRmmVdev | PdevAt(VdevAt(rdev.vdev_ptr) |
false | Virtual device |
| pdev | RmmPdev | PdevAt(vdev.pdev) |
false | Physical device |
| cfg | RsiDeviceInfo | RsiDeviceInfoAt(addr) |
false | Device configuration |
16.3.16.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.16.2 Failure conditions
| ID | Condition |
|---|---|
| da_en | pre: realm.feat_da != FEATURE_TRUE post: result == RSI_ERROR_STATE |
| vdev_id | pre: !RdevIdIsValid(realm, vdev_id) post: result == RSI_ERROR_INPUT |
| addr_align | pre: !AddrIsGranuleAligned(addr) post: result == RSI_ERROR_INPUT |
| addr_bound | pre: !AddrIsProtected(addr, realm) post: result == RSI_ERROR_INPUT |
16.3.16.2.1 Failure condition ordering
[da_en] < [vdev_id, addr_align, addr_bound]
16.3.16.3 Success conditions
| ID | Condition |
|---|---|
| hash_algo | Equal(cfg.hash_algo, pdev.hash_algo) |
16.3.16.4 Footprint
| ID | Value |
|---|---|
| state | rdev.state |
| operation | rdev.operation |
16.3.17 RSI_RDEV_GET_INTERFACE_REPORT command
Get Realm device interface report.
See also:
- Section 9.5.2
16.3.17.1 Interface
16.3.17.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001A6 |
| vdev_id | X1 | 63:0 | Bits64 | Realm device identifier |
| inst_id | X2 | 63:0 | UInt64 | Device instance identifier |
| version_max | X3 | 63:0 | UInt64 | Maximum TDISP version accepted by caller |
16.3.17.1.2 Context
The RSI_RDEV_GET_INTERFACE_REPORT command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rdev | RmmRdev | RdevFromIds( realm, vdev_id, inst_id) |
false | Realm device |
16.3.17.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| version | X1 | 63:0 | UInt64 | TDISP version |
16.3.17.2 Failure conditions
| ID | Condition |
|---|---|
| da_en | pre: realm.feat_da != FEATURE_TRUE post: result == RSI_ERROR_STATE |
| vdev_id | pre: !RdevIdsAreValid(realm, vdev_id, inst_id) post: result == RSI_ERROR_INPUT |
| version | pre: TDISP version is not supported. post: result == RSI_ERROR_INPUT |
| state | pre: (rdev.state != RDEV_LOCKED && rdev.state != RDEV_STARTED) post: result == RSI_ERROR_INPUT |
16.3.17.2.1 Failure condition ordering
[da_en] < [vdev_id, version]
[vdev_id] < [state]
16.3.17.3 Success conditions
| ID | Condition |
|---|---|
| locked | pre: rdev.state == RDEV_LOCKED post: rdev.state == RDEV_LOCKED_BUSY |
| started | pre: rdev.state == RDEV_STARTED post: rdev.state == RDEV_STARTED_BUSY |
| operation | rdev.operation == RDEV_OP_GET_INTERFACE_REPORT |
16.3.17.4 Footprint
| ID | Value |
|---|---|
| state | rdev.state |
| operation | rdev.operation |
16.3.18 RSI_RDEV_GET_MEASUREMENTS command
Get Realm device measurements.
See also:
- Section 9.5.2
16.3.18.1 Interface
16.3.18.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001A7 |
| vdev_id | X1 | 63:0 | Bits64 | Virtual device identifier |
| inst_id | X2 | 63:0 | UInt64 | Device instance identifier |
| params_ptr | X3 | 63:0 | Address | IPA of measurement parameters |
16.3.18.1.2 Context
The RSI_RDEV_GET_MEASUREMENTS command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rdev | RmmRdev | RdevFromIds( realm, vdev_id, inst_id) |
false | Realm device |
| params | RsiDeviceMeasurementsParams | RsiDeviceMeasurementsParamsAtRsiDeviceMeasParamsAt( params_ptr) |
false | Measurement parameters |
16.3.18.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.18.2 Failure conditions
| ID | Condition |
|---|---|
| da_en | pre: realm.feat_da != FEATURE_TRUE post: result == RSI_ERROR_STATE |
| vdev_id | pre: !RdevIdsAreValid(realm, vdev_id, inst_id) post: result == RSI_ERROR_INPUT |
| params | pre: !RdevMeasurementParamsValid(params) post: result == RSI_ERROR_INPUT |
| state | pre: (rdev.state != RDEV_NEW && rdev.state != RDEV_LOCKED && rdev.state != RDEV_STARTED) post: result == RSI_ERROR_INPUT |
16.3.18.2.1 Failure condition ordering
[da_en] < [vdev_id, params]
[vdev_id] < [state]
16.3.18.3 Success conditions
| ID | Condition |
|---|---|
| new | pre: rdev.state == RDEV_NEW post: rdev.state == RDEV_NEW_BUSY |
| locked | pre: rdev.state == RDEV_LOCKED post: rdev.state == RDEV_LOCKED_BUSY |
| started | pre: rdev.state == RDEV_STARTED post: rdev.state == RDEV_STARTED_BUSY |
| operation | rdev.operation == RDEV_OP_GET_MEASUREMENTS |
16.3.18.4 Footprint
| ID | Value |
|---|---|
| state | rdev.state |
| operation | rdev.operation |
16.3.19 RSI_RDEV_GET_STATE command
Get state of a Realm device.
See also:
- Section 9.5.5
16.3.19.1 Interface
16.3.19.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001A8 |
| vdev_id | X1 | 63:0 | Bits64 | Realm device identifier |
| inst_id | X2 | 63:0 | UInt64 | Device instance identifier |
16.3.19.1.2 Context
The RSI_RDEV_GET_STATE command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rdev | RmmRdev | RdevFromIds( realm, vdev_id, inst_id) |
false | Realm device |
16.3.19.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| state | X1 | 63:0 | RsiDeviceState | Realm device state |
16.3.19.2 Failure conditions
| ID | Condition |
|---|---|
| da_en | pre: realm.feat_da != FEATURE_TRUE post: result == RSI_ERROR_STATE |
| vdev_id | pre: !RdevIdsAreValid(realm, vdev_id, inst_id) post: result == RSI_ERROR_INPUT |
16.3.19.2.1 Failure condition ordering
[da_en] < [vdev_id]
16.3.19.3 Success conditions
| ID | Condition |
|---|---|
| state | Equal(state, rdev.state) |
16.3.19.4 Footprint
The RSI_RDEV_GET_STATE command does not have any footprint.
16.3.20 RSI_RDEV_LOCK command
Lock a Realm device.
See also:
- Section 9.5.5
16.3.20.1 Interface
16.3.20.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001A9 |
| vdev_id | X1 | 63:0 | Bits64 | Realm device identifier |
| inst_id | X2 | 63:0 | UInt64 | Device instance identifier |
16.3.20.1.2 Context
The RSI_RDEV_LOCK command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rdev | RmmRdev | RdevFromIds( realm, vdev_id, inst_id) |
false | Realm device |
16.3.20.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.20.2 Failure conditions
| ID | Condition |
|---|---|
| da_en | pre: realm.feat_da != FEATURE_TRUE post: result == RSI_ERROR_STATE |
| vdev_id | pre: !RdevIdsAreValid(realm, vdev_id, inst_id) post: result == RSI_ERROR_INPUT |
| state | pre: rdev.state != RDEV_NEW post: result == RSI_ERROR_INPUT |
16.3.20.2.1 Failure condition ordering
[da_en] < [vdev_id]
[vdev_id] < [state]
16.3.20.3 Success conditions
| ID | Condition |
|---|---|
| state | rdev.state == RDEV_NEW_BUSY |
| operation | rdev.operation == RDEV_OP_LOCK |
16.3.20.4 Footprint
| ID | Value |
|---|---|
| state | rdev.state |
| operation | rdev.operation |
16.3.21 RSI_RDEV_START command
Start a Realm device.
See also:
- Section 9.5.5
16.3.21.1 Interface
16.3.21.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001AA |
| vdev_id | X1 | 63:0 | Bits64 | Realm device identifier |
| inst_id | X2 | 63:0 | UInt64 | Device instance identifier |
16.3.21.1.2 Context
The RSI_RDEV_START command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rdev | RmmRdev | RdevFromIds( realm, vdev_id, inst_id) |
false | Realm device |
16.3.21.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.21.2 Failure conditions
| ID | Condition |
|---|---|
| da_en | pre: realm.feat_da != FEATURE_TRUE post: result == RSI_ERROR_STATE |
| vdev_id | pre: !RdevIdsAreValid(realm, vdev_id, inst_id) post: result == RSI_ERROR_INPUT |
| state | pre: rdev.state != RDEV_LOCKED post: result == RSI_ERROR_INPUT |
16.3.21.2.1 Failure condition ordering
[da_en] < [vdev_id]
[vdev_id] < [state]
16.3.21.3 Success conditions
| ID | Condition |
|---|---|
| state | rdev.state == RDEV_LOCKED_BUSY |
| operation | rdev.operation == RDEV_OP_START |
16.3.21.4 Footprint
| ID | Value |
|---|---|
| state | rdev.state |
| operation | rdev.operation |
16.3.22 RSI_RDEV_STOP command
Stop a Realm device.
See also:
- Section 9.5.5
16.3.22.1 Interface
16.3.22.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001AB |
| vdev_id | X1 | 63:0 | Bits64 | Realm device identifier |
| inst_id | X2 | 63:0 | UInt64 | Device instance identifier |
16.3.22.1.2 Context
The RSI_RDEV_STOP command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rdev | RmmRdev | RdevFromIds( realm, vdev_id, inst_id) |
false | Realm device |
16.3.22.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.22.2 Failure conditions
| ID | Condition |
|---|---|
| da_en | pre: realm.feat_da != FEATURE_TRUE post: result == RSI_ERROR_STATE |
| vdev_id | pre: !RdevIdsAreValid(realm, vdev_id, inst_id) post: result == RSI_ERROR_INPUT |
| state | pre: (rdev.state != RDEV_NEW && rdev.state != RDEV_LOCKED && rdev.state != RDEV_STARTED && rdev.state != RDEV_ERROR) post: result == RSI_ERROR_INPUT |
16.3.22.2.1 Failure condition ordering
[da_en] < [vdev_id]
[vdev_id] < [state]
16.3.22.3 Success conditions
| ID | Condition |
|---|---|
| state | rdev.state == RDEV_STOPPING |
16.3.22.4 Footprint
| ID | Value |
|---|---|
| state | rdev.state |
16.3.23 RSI_RDEV_VALIDATE_MAPPING command
Validate Realm device memory mappings.
See also:
- Section 9.5.3
16.3.23.1 Interface
16.3.23.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001AC |
| vdev_id | X1 | 63:0 | Bits64 | Realm device identifier |
| inst_id | X2 | 63:0 | UInt64 | Device instance identifier |
| ipa_base | X3 | 63:0 | Address | Base of target IPA region |
| ipa_top | X4 | 63:0 | Address | Top of target IPA region |
| pa_base | X5 | 63:0 | Address | Base of target PA region |
| flags | X6 | 63:0 | RsiRdevValidateIoFlags | Flags |
16.3.23.1.2 Context
The RSI_RDEV_VALIDATE_MAPPING command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| rec | RmmRec | CurrentRec() |
false | Current REC |
| rdev | RmmRdev | RdevFromIds( realm, vdev_id, inst_id) |
false | Realm device |
16.3.23.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| new_ipa_base | X1 | 63:0 | Address | Base of IPA region which was not modified by the command |
| response | X2 | 0:0 | RsiResponse | Whether the Host accepted or rejected the request |
The following unused bits of RSI_RDEV_VALIDATE_MAPPING output values MBZ: X2[63:1].
16.3.23.2 Failure conditions
| ID | Condition |
|---|---|
| da_en | pre: realm.feat_da != FEATURE_TRUE post: result == RSI_ERROR_STATE |
| vdev_id | pre: !RdevIdsAreValid(realm, vdev_id, inst_id) post: result == RSI_ERROR_INPUT |
| state | pre: (rdev.state != RDEV_LOCKED && rdev.state != RDEV_STARTED) post: result == RSI_ERROR_INPUT |
| ipa_base_align | pre: !AddrIsGranuleAligned(ipa_base) post: result == RSI_ERROR_INPUT |
| ipa_top_align | pre: !AddrIsGranuleAligned(ipa_top) post: result == RSI_ERROR_INPUT |
| pa_align | pre: !AddrIsGranuleAligned(pa_base) post: result == RSI_ERROR_INPUT |
| size_valid | pre: UInt(ipa_top) <= UInt(ipa_base) post: result == RSI_ERROR_INPUT |
| rgn_bound | pre: !AddrRangeIsProtected(ipa_base, ipa_top, realm) post: result == RSI_ERROR_INPUT |
16.3.23.2.1 Failure condition ordering
[da_en] < [vdev_id]
[vdev_id] < [state, ipa_base_align, ipa_top_align, pa_align,
size_valid, rgn_bound]
16.3.23.3 Success conditions
| ID | Condition |
|---|---|
| new_ipa_base | new_ipa_base == rec.ripas_addr |
| response | response == RecRipasResponseToRsi(rec) |
16.3.23.4 Footprint
The RSI_RDEV_VALIDATE_MAPPING command does not have any footprint.
16.3.24 RSI_REALM_CONFIG command
Read configuration for the current Realm.
16.3.24.1 Interface
16.3.24.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC40001AD |
| addr | X1 | 63:0 | Address | IPA of the Granule to which the configuration data will be written |
16.3.24.1.2 Context
The RSI_REALM_CONFIG command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| cfg | RsiRealmConfig | RsiRealmConfigAt(addr) |
false | Realm configuration |
16.3.24.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
16.3.24.2 Failure conditions
| ID | Condition |
|---|---|
| addr_align | pre: !AddrIsGranuleAligned(addr) post: result == RSI_ERROR_INPUT |
| addr_bound | pre: !AddrIsProtected(addr, realm) post: result == RSI_ERROR_INPUT |
16.3.24.2.1 Failure condition ordering
The RSI_REALM_CONFIG command does not have any failure condition orderings.
16.3.24.3 Success conditions
| ID | Condition |
|---|---|
| ipa_width | cfg.ipa_width == realm.ipa_width |
| hash_algo | Equal(cfg.hash_algo, realm.hash_algo) |
| num_aux_planes | cfg.num_aux_planes == realm.num_aux_planes |
16.3.24.4 Footprint
The RSI_REALM_CONFIG command does not have any footprint.
16.3.25 RSI_VERSION command
Returns RSI version.
On calling this command, the Realm provides a requested RSI version.
The output values include a status code and two revisions which are supported by the RMM: a lower revision and a higher revision.
- The higher revision value is the highest interface revision which is supported by the RMM.
- The lower revision is less than or equal to the higher revision.
The status code and lower revision output values indicate which of the following is true, in order of precedence:
The RMM supports an interface revision which is compatible with the requested revision.
- The status code is RSI_SUCCESS.
- The lower revision is equal to the requested revision.
The RMM does not support an interface revision which is compatible with the requested revision The RMM supports an interface revision which is incompatible with and less than the requested revision.
- The status code is RSI_ERROR_INPUT.
- The lower revision is the highest interface revision which is both less than the requested revision and supported by the RMM.
The RMM does not support an interface revision which is compatible with the requested revision The RMM supports an interface revision which is incompatible with and greater than the requested revision.
- The status code is RSI_ERROR_INPUT.
- The lower revision is equal to the higher revision.
16.3.25.1 Interface
16.3.25.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000190 |
| req | X1 | 63:0 | RsiInterfaceVersion | Requested interface revision |
16.3.25.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | RsiCommandReturnCode | Command return status |
| lower | X1 | 63:0 | RsiInterfaceVersion | Lower implemented interface revision |
| higher | X2 | 63:0 | RsiInterfaceVersion | Higher implemented interface revision |
16.3.25.2 Failure conditions
The RSI_VERSION command does not have any failure conditions.
16.3.25.3 Success conditions
The RSI_VERSION command does not have any success conditions.
16.3.25.4 Footprint
The RSI_VERSION command does not have any footprint.
16.4 RSI types
This section defines types which are used in the RSI interface.
16.4.1 RsiBoolean type
The RsiBoolean enumeration represents a boolean value.
The RsiBoolean enumeration is a concrete type.
The width of the RsiBoolean enumeration is 1 bits.
The values of the RsiBoolean enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_FALSE | False |
| 1 | RSI_TRUE | True |
The RsiBoolean enumeration is used in the following types:
16.4.2 RsiCommandReturnCode type
The RsiCommandReturnCode enumeration represents a return code from an RSI command.
The RsiCommandReturnCode enumeration is a concrete type.
The width of the RsiCommandReturnCode enumeration is 64 bits.
See also:
- Section 12
The values of the RsiCommandReturnCode enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_SUCCESS | Command completed successfully |
| 1 | RSI_ERROR_INPUT | The value of a command input value caused the command to fail |
| 2 | RSI_ERROR_STATE | The state of the current Realm or current REC does not match the state expected by the command |
| 3 | RSI_INCOMPLETE | The operation requested by the command is not complete |
| 4 | RSI_ERROR_UNKNOWN | The operation requested by the command failed for an unknown reason |
| 5 | RSI_ERROR_DEVICE | The state of a Realm device does not match the state expected by the command |
Unused encodings for the RsiCommandReturnCode enumeration are reserved for use by future versions of this specification.
16.4.3 RsiDeviceInfo type
The RsiDeviceInfo structure contains device configuration information.
The RsiDeviceInfo structure is a concrete type.
The width of the RsiDeviceInfo structure is 512 (0x200)
bytes.
The members of the RsiDeviceInfo structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| inst_id | 0x0 |
UInt64 | Instance identifier |
| cert_id | 0x8 |
UInt64 | Certificate identifier |
| hash_algo | 0x10 |
RsiHashAlgorithm | Algorithm used to generate device digests |
| cert_digest | 0x40 |
Bits512 | Certificate digest |
| key_digest | 0x80 |
Bits512 | Device public key digest |
| meas_digest | 0xc0 |
Bits512 | Measurement block digest |
| report_digest | 0x100 |
Bits512 | Interface report digest |
Unused bits of the RsiDeviceInfo structure MBZ.
16.4.4 RsiDeviceMeasurementsParams type
The RsiDeviceMeasurementsParams structure contains parameters for retrieval of Realm device measurements.
The RsiDeviceMeasurementsParams structure is a concrete type.
The width of the RsiDeviceMeasurementsParams structure is 64
(0x40) bytes.
The members of the RsiDeviceMeasurementsParams structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| meas_ids[256] | 0x0 |
RsiBoolean | Measurement indices For each index, if the array element is RSI_TRUE then the RMM is requested to retrieve the corresponding device measurement. |
| meas_params[256] | 0x20 |
RsiBoolean | Measurement parameters |
16.4.5 RsiDeviceState type
The RsiDeviceState enumeration represents state of an assigned Realm device.
The RsiDeviceState enumeration is a concrete type.
The width of the RsiDeviceState enumeration is 64 bits.
See also:
- Section 9.5
The values of the RsiDeviceState enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_RDEV_NEW | Device interface is unlocked. |
| 1 | RSI_RDEV_NEW_BUSY | Device interface is unlocked and is handling an interruptible Realm device operation. |
| 2 | RSI_RDEV_LOCKED | Device interface is locked. |
| 3 | RSI_RDEV_LOCKED_BUSY | Device interface is locked and is handling an interruptible Realm device operation. |
| 4 | RSI_RDEV_STARTED | Device interface is started. |
| 5 | RSI_RDEV_STARTED_BUSY | Device interface is started and is handling an interruptible Realm device operation. |
| 6 | RSI_RDEV_STOPPING | Device interface is stopping. |
| 7 | RSI_RDEV_STOPPED | Device interface is stopped. |
| 8 | RSI_RDEV_ERROR | Device interface has reported a fatal error. |
Unused encodings for the RsiDeviceState enumeration are reserved for use by future versions of this specification.
16.4.6 RsiDevMemCoherent type
The RsiDevMemCoherent enumeration represents whether a device memory location is within the system coherent memory space.
The RsiDevMemCoherent enumeration is a concrete type.
The width of the RsiDevMemCoherent enumeration is 1 bits.
The values of the RsiDevMemCoherent enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_DEV_MEM_NON_COHERENT | A device memory location is not within the system coherent memory space |
| 1 | RSI_DEV_MEM_COHERENT | A device memory location is within the system coherent memory space |
The RsiDevMemCoherent enumeration is used in the following types:
16.4.7 RsiDevMemShared type
The RsiDevMemShared enumeration represents whether a device memory mapping is shared.
The RsiDevMemShared enumeration is a concrete type.
The width of the RsiDevMemShared enumeration is 1 bits.
The values of the RsiDevMemShared enumeration are shown in the following table.
The RsiDevMemShared enumeration is used in the following types:
16.4.8 RsiFeature type
The RsiFeature enumeration represents whether a feature is enabled.
The RsiFeature enumeration is a concrete type.
The width of the RsiFeature enumeration is 1 bits.
The values of the RsiFeature enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_FEATURE_FALSE | Feature is not enabled. |
| 1 | RSI_FEATURE_TRUE | Feature is enabled. |
The RsiFeature enumeration is used in the following types:
16.4.9 RsiFeatureRegister0 type
The RsiFeatureRegister0 fieldset contains RSI feature register 0.
The RsiFeatureRegister0 fieldset is a concrete type.
The width of the RsiFeatureRegister0 fieldset is 64 bits.
The fields of the RsiFeatureRegister0 fieldset are shown in the following diagram.
The fields of the RsiFeatureRegister0 fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| DA | 0 | Whether Realm device assignment is supported | RsiFeature |
| MRO | 1 | Whether “mostly read-only” permissions are supported | RsiFeature |
| 63:2 | Reserved | MBZ |
16.4.10 RsiGicOwner type
The RsiGicOwner enumeration represents which Plane is GIC owner.
The RsiGicOwner enumeration is a concrete type.
The width of the RsiGicOwner enumeration is 1 bits.
The values of the RsiGicOwner enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_GIC_OWNER_0 | Plane 0 is GIC owner. |
| 1 | RSI_GIC_OWNER_N | Plane N is GIC owner. |
The RsiGicOwner enumeration is used in the following types:
16.4.11 RsiHashAlgorithm type
The RsiHashAlgorithm enumeration represents hash algorithm.
The RsiHashAlgorithm enumeration is a concrete type.
The width of the RsiHashAlgorithm enumeration is 8 bits.
See also:
- Section 16.3.24
The values of the RsiHashAlgorithm enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_HASH_SHA_256 | SHA-256 (Secure Hash Standard (SHS) [19]) |
| 1 | RSI_HASH_SHA_512 | SHA-512 (Secure Hash Standard (SHS) [19]) |
Unused encodings for the RsiHashAlgorithm enumeration are reserved for use by future versions of this specification.
The RsiHashAlgorithm enumeration is used in the following types:
16.4.12 RsiHostCall type
The RsiHostCall structure contains data structure used to pass Host call arguments and return values.
The RsiHostCall structure is a concrete type.
The width of the RsiHostCall structure is 256 (0x100)
bytes.
The members of the RsiHostCall structure are shown in the following table.
Unused bits of the RsiHostCall structure SBZ.
16.4.13 RsiInterfaceVersion type
The RsiInterfaceVersion fieldset contains an RSI interface version.
The RsiInterfaceVersion fieldset is a concrete type.
The width of the RsiInterfaceVersion fieldset is 64 bits.
The fields of the RsiInterfaceVersion fieldset are shown in the following diagram.
The fields of the RsiInterfaceVersion fieldset are shown in the following table.
16.4.14 RsiPlaneEnter type
The RsiPlaneEnter structure contains data passed from P0 to the RMM on Plane entry.
The RsiPlaneEnter structure is a concrete type.
The width of the RsiPlaneEnter structure is 2048 (0x800)
bytes.
The members of the RsiPlaneEnter structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| flags | 0x0 |
RsiPlaneEnterFlags | Flags |
| pc | 0x8 |
Bits64 | Program counter |
| gprs[31] | 0x100 |
Bits64 | Registers |
| gicv3_hcr | 0x200 |
Bits64 | GICv3 Hypervisor Control Register value |
| gicv3_lrs[16] | 0x208 |
Bits64 | GICv3 List Register values |
Unused bits of the RsiPlaneEnter structure SBZ.
The RsiPlaneEnter structure is used in the following types:
16.4.15 RsiPlaneEnterFlags type
The RsiPlaneEnterFlags fieldset contains flags provided by P0 during Plane entry.
The RsiPlaneEnterFlags fieldset is a concrete type.
The width of the RsiPlaneEnterFlags fieldset is 64 bits.
The fields of the RsiPlaneEnterFlags fieldset are shown in the following diagram.
The fields of the RsiPlaneEnterFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| trap_wfi | 0 | Whether to trap WFI execution by the Plane. | RsiTrap |
| trap_wfe | 1 | Whether to trap WFE execution by the Plane. | RsiTrap |
| trap_hc | 2 | Whether to trap RSI_HOST_CALL execution by the Plane. RSI_TRAP: execution of RSI_HOST_CALL causes Plane exit RSI_NO_TRAP: execution of RSI_HOST_CALL causes REC exit to Host |
RsiTrap |
| gic_owner | 3 | Whether to transfer GIC ownership to the target Plane. | RsiGicOwner |
| 63:4 | Reserved | SBZ |
The RsiPlaneEnterFlags fieldset is used in the following types:
16.4.16 RsiPlaneExit type
The RsiPlaneExit structure contains data passed from the RMM to P0 on Plane exit.
The RsiPlaneExit structure is a concrete type.
The width of the RsiPlaneExit structure is 2048 (0x800)
bytes.
The members of the RsiPlaneExit structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| reason | 0x0 |
RsiPlaneExitReason | Exit reason |
| elr_el2 | 0x100 |
Bits64 | Exception Link Register |
| esr_el2 | 0x108 |
Bits64 | Exception Syndrome Register |
| far_el2 | 0x110 |
Bits64 | Fault Address Register |
| hpfar_el2 | 0x118 |
Bits64 | Hypervisor IPA Fault Address register |
| gprs[31] | 0x200 |
Bits64 | Registers |
| gicv3_hcr | 0x300 |
Bits64 | GICv3 Hypervisor Control Register value |
| gicv3_lrs[16] | 0x308 |
Bits64 | GICv3 List Register values |
| gicv3_misr | 0x388 |
Bits64 | GICv3 Maintenance Interrupt State Register value |
| gicv3_vmcr | 0x390 |
Bits64 | GICv3 Virtual Machine Control Register value |
| cntp_ctl | 0x400 |
Bits64 | Counter-timer Physical Timer Control Register value |
| cntp_cval | 0x408 |
Bits64 | Counter-timer Physical Timer CompareValue Register value |
| cntv_ctl | 0x410 |
Bits64 | Counter-timer Virtual Timer Control Register value |
| cntv_cval | 0x418 |
Bits64 | Counter-timer Virtual Timer CompareValue Register value |
Unused bits of the RsiPlaneExit structure SBZ.
The RsiPlaneExit structure is used in the following types:
16.4.17 RsiPlaneExitReason type
The RsiPlaneExitReason enumeration represents the reason for a Plane exit.
The RsiPlaneExitReason enumeration is a concrete type.
The width of the RsiPlaneExitReason enumeration is 8 bits.
The values of the RsiPlaneExitReason enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_EXIT_SYNC | Plane exit due to synchronous exception |
Unused encodings for the RsiPlaneExitReason enumeration are reserved for use by future versions of this specification.
The RsiPlaneExitReason enumeration is used in the following types:
16.4.18 RsiPlaneRun type
The RsiPlaneRun structure contains fields used to share information between RMM and P0 during Plane entry and Plane exit.
The RsiPlaneRun structure is a concrete type.
The width of the RsiPlaneRun structure is 4096 (0x1000)
bytes.
The members of the RsiPlaneRun structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| enter | 0x0 |
RsiPlaneEnter | Entry information |
| exit | 0x800 |
RsiPlaneExit | Exit information |
16.4.19 RsiRdevValidateIoFlags type
The RsiRdevValidateIoFlags fieldset contains flags provided when requesting validation of a device memory mapping.
The RsiRdevValidateIoFlags fieldset is a concrete type.
The width of the RsiRdevValidateIoFlags fieldset is 64 bits.
The fields of the RsiRdevValidateIoFlags fieldset are shown in the following diagram.
The fields of the RsiRdevValidateIoFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| share | 0 | Whether the device memory mapping is shared. | RsiDevMemShared |
| coh | 1 | Whether the output address of the device memory mapping is within the system coherent memory space. | RsiDevMemCoherent |
| 63:2 | Reserved | SBZ |
16.4.20 RsiRealmConfig type
The RsiRealmConfig structure contains realm configuration.
The RsiRealmConfig structure is a concrete type.
The width of the RsiRealmConfig structure is 4096
(0x1000) bytes.
See also:
- Section 16.3.24
The members of the RsiRealmConfig structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| ipa_width | 0x0 |
UInt64 | IPA width in bits |
| hash_algo | 0x8 |
RsiHashAlgorithm | Hash algorithm |
| num_aux_planes | 0x10 |
UInt64 | Number of auxiliary Planes |
| gicv3_vtr | 0x18 |
Bits64 | GICv3 VGIC Type Register value |
| rpv | 0x200 |
Bits512 | Realm Personalization Value |
Unused bits of the RsiRealmConfig structure MBZ.
16.4.21 RsiResponse type
The RsiResponse enumeration represents whether the Host accepted or rejected a Realm request.
The RsiResponse enumeration is a concrete type.
The width of the RsiResponse enumeration is 1 bits.
The values of the RsiResponse enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_ACCEPT | Host accepted the Realm request. |
| 1 | RSI_REJECT | Host rejected the Realm request. |
16.4.22 RsiRipas type
The RsiRipas enumeration represents realm IPA state.
The RsiRipas enumeration is a concrete type.
The width of the RsiRipas enumeration is 8 bits.
The values of the RsiRipas enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_EMPTY | Address where no Realm resources are mapped. |
| 1 | RSI_RAM | Address where private code or data owned by the Realm is mapped. |
| 2 | RSI_DESTROYED | Address which is inaccessible to the Realm due to an action taken by the Host. |
| 3 | RSI_DEV | Address where memory of an assigned Realm device is mapped. |
Unused encodings for the RsiRipas enumeration are reserved for use by future versions of this specification.
16.4.23 RsiRipasChangeDestroyed type
The RsiRipasChangeDestroyed enumeration represents whether a RIPAS change from DESTROYED should be permitted.
The RsiRipasChangeDestroyed enumeration is a concrete type.
The width of the RsiRipasChangeDestroyed enumeration is 1 bits.
The values of the RsiRipasChangeDestroyed enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_NO_CHANGE_DESTROYED | A RIPAS change from DESTROYED should not be permitted. |
| 1 | RSI_CHANGE_DESTROYED | A RIPAS change from DESTROYED should be permitted. |
The RsiRipasChangeDestroyed enumeration is used in the following types:
16.4.24 RsiRipasChangeFlags type
The RsiRipasChangeFlags fieldset contains flags provided by the Realm when requesting a RIPAS change.
The RsiRipasChangeFlags fieldset is a concrete type.
The width of the RsiRipasChangeFlags fieldset is 64 bits.
The fields of the RsiRipasChangeFlags fieldset are shown in the following diagram.
The fields of the RsiRipasChangeFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| destroyed | 0 | Whether a RIPAS change from DESTROYED should be permitted | RsiRipasChangeDestroyed |
| 63:1 | Reserved | SBZ |
16.4.25 RsiTrap type
The RsiTrap enumeration represents whether a trap is enabled.
The RsiTrap enumeration is a concrete type.
The width of the RsiTrap enumeration is 1 bits.
The values of the RsiTrap enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | RSI_NO_TRAP | Trap is disabled. |
| 1 | RSI_TRAP | Trap is enabled. |
The RsiTrap enumeration is used in the following types:
17 Power State Control Interface
This section describes how Power State Control Interface (PSCI) function execution by a Realm execution of SMC instructions is handled.
17.1 PSCI overview
In this section,
recrefers to the currently executing RECexitrefer to the RmiRecExit object which was provided to the RMI_REC_ENTER commandtarget_recrefers to the REC object identified by an MPIDR value passed to a PSCI function.
The RMM provides a trusted implementation of parts of the PSCI ABI. This section describes the checks performed by the RMM when a Realm executes a PSCI command, and the internal RMM state changes which result from a successful PSCI command execution. Successful execution by the RMM of some PSCI commands results in a REC exit due to PSCI, which allows the Host to perform further processing of the command.
The HVC conduit for PSCI is not supported for Realms.
See also:
- Arm Power State Coordination Interface (PSCI) [22]
- Section 2.3.2
- Section 4.3.7
- Section 4.5
- Section 21.4
17.2 PSCI version
The RMM must support version >= 1.1 of the Power State Control Interface.
See also:
- Section 17.3.8
17.3 PSCI commands
The following table summarizes the FIDs of commands in the PSCI interface.
| FID | Command |
|---|---|
0x84000000 |
PSCI_VERSION |
| … | |
0x84000002 |
PSCI_CPU_OFF |
| … | |
0x84000008 |
PSCI_SYSTEM_OFF |
0x84000009 |
PSCI_SYSTEM_RESET |
0x8400000A |
PSCI_FEATURES |
| … | |
0xC4000001 |
PSCI_CPU_SUSPEND |
| … | |
0xC4000003 |
PSCI_CPU_ON |
0xC4000004 |
PSCI_AFFINITY_INFO |
17.3.1 PSCI_AFFINITY_INFO command
Query status of a VPE.
17.3.1.1 Interface
17.3.1.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000004 |
| target_affinity | X1 | 63:0 | Bits64 | This parameter contains a copy of the affinity fields of the MPIDR register |
| lowest_affinity_leve l | X2 | 31:0 | UInt32 | Denotes the lowest affinity level field that is valid in the target_affinity parameter |
The following unused bits of PSCI_AFFINITY_INFO input values SBZ: X2[63:32].
17.3.1.1.2 Context
The PSCI_AFFINITY_INFO command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| target_rec | RmmRec | RecFromMpidr( target_affinity) |
false | Target REC |
17.3.1.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | PsciReturnCode | Command return code |
17.3.1.2 Failure conditions
| ID | Condition |
|---|---|
| target_bound | pre: lowest_affinity_level != 0 post: result == PSCI_INVALID_PARAMETERS |
| target_match | pre: !MpidrIsUsed(target_affinity) post: result == PSCI_INVALID_PARAMETERS |
17.3.1.2.1 Failure condition ordering
The PSCI_AFFINITY_INFO command does not have any failure condition orderings.
17.3.1.3 Success conditions
| ID | Condition |
|---|---|
| runnable | pre: target_rec.flags.runnable == RUNNABLE post: result == PSCI_SUCCESS |
| not_runnable | pre: target_rec.flags.runnable == NOT_RUNNABLE post: result == PSCI_OFF |
17.3.1.4 Footprint
The PSCI_AFFINITY_INFO command does not have any footprint.
17.3.2 PSCI_CPU_OFF command
Power down the calling core.
17.3.2.1 Interface
17.3.2.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0x84000002 |
17.3.2.1.2 Context
The PSCI_CPU_OFF command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| rec | RmmRec | CurrentRec() |
false | Current REC |
17.3.2.1.3 Output values
The PSCI_CPU_OFF command does not have any output values.
Following execution of PSCI_CPU_OFF, control does not return to the caller.
17.3.2.2 Failure conditions
The PSCI_CPU_OFF command does not have any failure conditions.
17.3.2.3 Success conditions
The PSCI_CPU_OFF command does not have any success conditions.
Following execution of PSCI_CPU_OFF, control does not return to the caller.
17.3.2.4 Footprint
The PSCI_CPU_OFF command does not have any footprint.
17.3.3 PSCI_CPU_ON command
Power up a core.
17.3.3.1 Interface
17.3.3.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000003 |
| target_cpu | X1 | 63:0 | Bits64 | This parameter contains a copy of the affinity fields of the MPIDR register |
| entry_point_address | X2 | 63:0 | Address | Address at which the core must resume execution |
| context_id | X3 | 31:0 | UInt32 | This parameter is only meaningful to the caller (must be present in X0 of the target PE upon first entry to Non-Secure exception level) |
The following unused bits of PSCI_CPU_ON input values SBZ: X3[63:32].
17.3.3.1.2 Context
The PSCI_CPU_ON command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
| target_rec | RmmRec | RecFromMpidr(target_cpu) |
false | Target REC |
17.3.3.1.3 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | PsciReturnCode | Command return code |
17.3.3.2 Failure conditions
| ID | Condition |
|---|---|
| entry | pre: !AddrIsProtected(entry_point_address, realm) post: result == PSCI_INVALID_ADDRESS |
| mpidr | pre: !MpidrIsUsed(target_cpu) post: result == PSCI_INVALID_PARAMETERS |
| runnable | pre: target_rec.flags.runnable == RUNNABLE post: result == PSCI_ALREADY_ON |
17.3.3.2.1 Failure condition ordering
The PSCI_CPU_ON command does not have any failure condition orderings.
17.3.3.3 Success conditions
| ID | Condition |
|---|---|
| entry | target_rec.pc == ToBits64(UInt(entry_point_address)) |
| runnable | target_rec.flags.runnable == RUNNABLE |
17.3.3.4 Footprint
| ID | Value |
|---|---|
| runnable | target_rec.flags.runnable |
17.3.4 PSCI_CPU_SUSPEND command
Suspend execution on the calling VPE.
17.3.4.1 Interface
17.3.4.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0xC4000001 |
| power_state | X1 | 31:0 | UInt32 | Identifier for a specific local state |
| entry_point_address | X2 | 63:0 | Address | Address at which the core must resume execution |
| context_id | X3 | 63:0 | UInt64 | This parameter is only meaningful to the caller (must be present in X0 upon first entry to Non- Secure exception level) |
The following unused bits of PSCI_CPU_SUSPEND input values SBZ: X1[63:32].
The RMM treats all target power states as suspend requests, and
therefore the entry_point_address and
context_id arguments are ignored.
17.3.4.1.2 Output values
The PSCI_CPU_SUSPEND command does not have any output values.
Following execution of PSCI_CPU_SUSPEND, control does not return to the caller.
17.3.4.2 Failure conditions
The PSCI_CPU_SUSPEND command does not have any failure conditions.
17.3.4.3 Success conditions
The PSCI_CPU_SUSPEND command does not have any success conditions.
Following execution of PSCI_CPU_SUSPEND, control does not return to the caller.
17.3.4.4 Footprint
The PSCI_CPU_SUSPEND command does not have any footprint.
17.3.5 PSCI_FEATURES command
Query whether a specific PSCI feature is implemented.
17.3.5.1 Interface
17.3.5.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0x8400000A |
| psci_func_id | X1 | 31:0 | UInt32 | Function ID for a PSCI Function |
The following unused bits of PSCI_FEATURES input values SBZ: X1[63:32].
17.3.5.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | PsciReturnCode | Command return code |
17.3.5.2 Failure conditions
The PSCI_FEATURES command does not have any failure conditions.
17.3.5.3 Success conditions
| ID | Condition |
|---|---|
| func_ok | pre: psci_func_id is a supported PSCI function. post: result == PSCI_SUCCESS |
| func_not_ok | pre: psci_func_id is not a supported PSCI function. post: result == PSCI_NOT_SUPPORTED |
17.3.5.4 Footprint
The PSCI_FEATURES command does not have any footprint.
17.3.6 PSCI_SYSTEM_OFF command
Shut down the system.
17.3.6.1 Interface
17.3.6.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0x84000008 |
17.3.6.1.2 Context
The PSCI_SYSTEM_OFF command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
17.3.6.1.3 Output values
The PSCI_SYSTEM_OFF command does not have any output values.
Following execution of PSCI_SYSTEM_OFF, control does not return to the caller.
17.3.6.2 Failure conditions
The PSCI_SYSTEM_OFF command does not have any failure conditions.
17.3.6.3 Success conditions
| ID | Condition |
|---|---|
| state | realm.state == REALM_SYSTEM_OFF |
Following execution of PSCI_SYSTEM_OFF, control does not return to the caller.
17.3.6.4 Footprint
The PSCI_SYSTEM_OFF command does not have any footprint.
17.3.7 PSCI_SYSTEM_RESET command
Shut down the system.
17.3.7.1 Interface
17.3.7.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0x84000009 |
17.3.7.1.2 Context
The PSCI_SYSTEM_RESET command operates on the following context.
| Name | Type | Value | Before | Description |
|---|---|---|---|---|
| realm | RmmRealm | CurrentRealm() |
false | Current Realm |
17.3.7.1.3 Output values
The PSCI_SYSTEM_RESET command does not have any output values.
Following execution of PSCI_SYSTEM_RESET, control does not return to the caller.
17.3.7.2 Failure conditions
The PSCI_SYSTEM_RESET command does not have any failure conditions.
17.3.7.3 Success conditions
| ID | Condition |
|---|---|
| state | realm.state == REALM_SYSTEM_OFF |
Following execution of PSCI_SYSTEM_RESET, control does not return to the caller.
17.3.7.4 Footprint
The PSCI_SYSTEM_RESET command does not have any footprint.
17.3.8 PSCI_VERSION command
Query the version of PSCI implemented.
17.3.8.1 Interface
17.3.8.1.1 Input values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| fid | X0 | 63:0 | UInt64 | FID, value 0x84000000 |
17.3.8.1.2 Output values
| Name | Register | Bits | Type | Description |
|---|---|---|---|---|
| result | X0 | 63:0 | PsciInterfaceVersion | Interface version |
See also:
- Section 17.2
17.3.8.2 Failure conditions
The PSCI_VERSION command does not have any failure conditions.
17.3.8.3 Success conditions
The PSCI_VERSION command does not have any success conditions.
17.3.8.4 Footprint
The PSCI_VERSION command does not have any footprint.
17.4 PSCI types
This section defines types which are used in the PSCI interface.
17.4.1 PsciInterfaceVersion type
The PsciInterfaceVersion fieldset contains an PSCI interface version.
The PsciInterfaceVersion fieldset is a concrete type.
The width of the PsciInterfaceVersion fieldset is 64 bits.
The fields of the PsciInterfaceVersion fieldset are shown in the following diagram.
The fields of the PsciInterfaceVersion fieldset are shown in the following table.
17.4.2 PsciReturnCode type
The PsciReturnCode enumeration represents the return code of a PSCI command.
The PsciReturnCode enumeration is a concrete type.
The width of the PsciReturnCode enumeration is 64 bits.
The values of the PsciReturnCode enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| -9 | PSCI_INVALID_ADDRESS | Refer to PSCI specification |
| -8 | PSCI_DISABLED | Refer to PSCI specification |
| -7 | PSCI_NOT_PRESENT | Refer to PSCI specification |
| -6 | PSCI_INTERNAL_FAILURE | Refer to PSCI specification |
| -5 | PSCI_ON_PENDING | Refer to PSCI specification |
| -4 | PSCI_ALREADY_ON | Refer to PSCI specification |
| -3 | PSCI_DENIED | Refer to PSCI specification |
| -2 | PSCI_INVALID_PARAMETERS | Refer to PSCI specification |
| -1 | PSCI_NOT_SUPPORTED | Refer to PSCI specification |
| 0 | PSCI_SUCCESS | Refer to PSCI specification |
| 1 | PSCI_OFF | Refer to PSCI specification |
Unused encodings for the PsciReturnCode enumeration are reserved for use by future versions of this specification.
18 RMM constants
This section describes constants which are used in the definition of RMM commands or RMM abstract state.
18.1 RMM_GRANULE_SIZE
Size of a Granule in bytes.
The value of RMM_GRANULE_SIZE is 0x1000.
18.2 RMM_NUM_PERM_OVERLAY_INDICES
Number of permission overlay indices.
The value of RMM_NUM_PERM_OVERLAY_INDICES is 15.
18.3 RMM_RTT_BLOCK_LEVEL
RTT level of a block entry.
The value of RMM_RTT_BLOCK_LEVEL is 2.
18.4 RMM_RTT_PAGE_LEVEL
RTT level of a page entry.
The value of RMM_RTT_PAGE_LEVEL is 3.
18.5 RMM_RTT_TREE_PRIMARY
Index of primary RTT tree.
The value of RMM_RTT_TREE_PRIMARY is 0.
19 RMM types
This section describes types which are used to model the abstract state of the RMM.
19.1 RmmAddressRange type
The RmmAddressRange structure contains address range.
The RmmAddressRange structure is an abstract type.
The members of the RmmAddressRange structure are shown in the following table.
The RmmAddressRange structure is used in the following types:
19.2 RmmBoolean type
The RmmBoolean enumeration represents whether a feature is enabled.
The RmmBoolean enumeration is an abstract type.
The values of the RmmBoolean enumeration are shown in the following table.
| Name | Description |
|---|---|
| RMM_FALSE | False |
| RMM_TRUE | True |
The RmmBoolean enumeration is used in the following types:
19.3 RmmDataFlags type
The RmmDataFlags fieldset contains flags provided by the Host during DATA Granule creation.
The RmmDataFlags fieldset is a concrete type.
The width of the RmmDataFlags fieldset is 64 bits.
The fields of the RmmDataFlags fieldset are shown in the following diagram.
The fields of the RmmDataFlags fieldset are shown in the following table.
| Name | Bits | Description | Value |
|---|---|---|---|
| measure | 0 | Whether to measure DATA Granule contents | RmmDataMeasureContent |
| 63:1 | Reserved | SBZ |
The RmmDataFlags fieldset is used in the following types:
19.4 RmmDataMeasureContent type
The RmmDataMeasureContent enumeration represents whether to measure DATA Granule contents.
The RmmDataMeasureContent enumeration is a concrete type.
The width of the RmmDataMeasureContent enumeration is 1 bits.
The values of the RmmDataMeasureContent enumeration are shown in the following table.
| Encoding | Name | Description |
|---|---|---|
| 0 | NO_MEASURE_CONTENT | Do not measure DATA Granule contents. |
| 1 | MEASURE_CONTENT | Measure DATA Granule contents. |
The RmmDataMeasureContent enumeration is used in the following types:
19.5 RmmDevCommState type
The RmmDevCommState enumeration represents the state of communication between an RMM device object and a device.
The RmmDevCommState enumeration is an abstract type.
The values of the RmmDevCommState enumeration are shown in the following table.
| Name | Description |
|---|---|
| DEV_COMM_ACTIVE | The RMM has initiated a device transaction. One or more device requests associated with this device transaction have been sent from the RMM to the device. The RMM has not received all the expected device responses associated with this device transaction. |
| DEV_COMM_ERROR | The RMM encountered an error during communication with the device. |
| DEV_COMM_IDLE | The RMM is not communicating with the device. |
| DEV_COMM_PENDING | The RMM has a device request which is ready to be sent to the device. |
The RmmDevCommState enumeration is used in the following types:
19.6 RmmDevMemShared type
The RmmDevMemShared enumeration represents whether device memory is shared.
The RmmDevMemShared enumeration is an abstract type.
The values of the RmmDevMemShared enumeration are shown in the following table.
The RmmDevMemShared enumeration is used in the following types:
19.7 RmmFeature type
The RmmFeature enumeration represents whether a feature is enabled.
The RmmFeature enumeration is an abstract type.
See also:
- Section 3
The values of the RmmFeature enumeration are shown in the following table.
| Name | Description |
|---|---|
| FEATURE_FALSE |
|
| FEATURE_TRUE |
|
The RmmFeature enumeration is used in the following types:
19.8 RmmFeatures type
The RmmFeatures structure contains features supported by RMM implementation.
The RmmFeatures structure is an abstract type.
See also:
- Section 3
The members of the RmmFeatures structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| max_ipa_width | UInt64 | Maximum IPA width |
| feat_lpa2 | RmmFeature | Whether LPA2 is supported |
| feat_sve | RmmFeature | Whether SVE is supported |
| max_sve_vl | UInt64 | Maximum SVE vector length |
| num_bps | UInt64 | Number of breakpoints available |
| num_wps | UInt64 | Number of watchpoints available |
| feat_pmu | RmmFeature | Number of watchpoints available |
| pmu_num_ctrs | UInt64 | Number of PMU counters available |
| feat_sha_256 | RmmFeature | Whether SHA-256 is supported |
| feat_sha_512 | RmmFeature | Whether SHA-512 is supported |
| feat_da | RmmFeature | Whether Realm device assignment is supported |
| max_num_aux_planes | UInt64 | Maximum number of auxiliary Planes |
| plane_rtt | RmmPlaneRttFeature | RTT usage models supported for multi-Plane Realms |
| max_mecid | Bits64 | Maximum supported MECID |
| max_recs_order | UInt64 | Order of the maximum number of RECs which can be created per Realm |
| gicv3_num_lrs | UInt64 | Number of GICv3 List Registers which are available. |
19.9 RmmGptEntry type
The RmmGptEntry enumeration represents granule Protection Table entry.
The RmmGptEntry enumeration is an abstract type.
See also:
- Section 14.2930
The values of the RmmGptEntry enumeration are shown in the following table.
| Name | Description |
|---|---|
| GPT_AAP | Access permitted via any PAS. |
| GPT_NS | Access permitted via Non-secure PAS only. |
| GPT_REALM | Access permitted via Realm PAS only. |
| GPT_ROOT | Access permitted via Root PAS only. |
| GPT_SECURE | Access permitted via Secure PAS only. |
The RmmGptEntry enumeration is used in the following types:
19.10 RmmGranule type
The RmmGranule structure contains attributes of a Granule.
The RmmGranule structure is an abstract type.
The members of the RmmGranule structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| gpt | RmmGptEntry | GPT entry |
| state | RmmGranuleState | Lifecycle state |
19.11 RmmGranuleState type
The RmmGranuleState enumeration represents the state of a granule.
The RmmGranuleState enumeration is an abstract type.
The values of the RmmGranuleState enumeration are shown in the following table.
| Name | Description |
|---|---|
| DATA | Realm code or data. |
| DELEGATED | Delegated for use by the RMM. |
| DEV_DELEGATED_PRIVATE | Device memory, delegated to the RMM and accessible via Realm PAS only. |
| DEV_DELEGATED_SHARED | Device memory, delegated to the RMM and accessible via any PAS. |
| DEV_PRIVATE | Device memory, mapped into a Realm and inaccessible by other requestors. |
| DEV_SHARED | Device memory, mapped into a Realm and also accessible by other requestors. |
| DEV_UNDELEGATED | Device memory, not delegated for use by the RMM. |
| PDEV | Physical device. |
| PDEV_AUX | Physical device auxiliary Granule. |
| RD | Realm Descriptor. |
| REC | Realm Execution Context. |
| REC_AUX | Realm Execution Context auxiliary Granule. |
| RTT | Realm Translation Table. |
| UNDELEGATED | Not delegated for use by the RMM. |
| VDEV | Virtual device. |
| VDEV_AUX | Virtual device auxiliary Granule. |
The RmmGranuleState enumeration is used in the following types:
19.12 RmmHashAlgorithm type
The RmmHashAlgorithm enumeration represents hash algorithm.
The RmmHashAlgorithm enumeration is an abstract type.
The values of the RmmHashAlgorithm enumeration are shown in the following table.
| Name | Description |
|---|---|
| HASH_SHA_256 | SHA-256 (Secure Hash Standard (SHS) [19]) |
| HASH_SHA_512 | SHA-512 (Secure Hash Standard (SHS) [19]) |
The RmmHashAlgorithm enumeration is used in the following types:
19.13 RmmHipas type
The RmmHipas enumeration represents host IPA state.
The RmmHipas enumeration is an abstract type.
The values of the RmmHipas enumeration are shown in the following table.
| Name | Description |
|---|---|
| HIPAS_ASSIGNED | Protected IPA which is associated with a DATA Granule. |
| HIPAS_ASSIGNED_DEV_PRIVATE | Protected IPA which is associated with a DEV_PRIVATE Granule. |
| HIPAS_ASSIGNED_DEV_SHARED | Protected IPA which is associated with a DEV_SHARED Granule. |
| HIPAS_ASSIGNED_NS | Unprotected IPA which is associated with an NS Granule. |
| HIPAS_UNASSIGNED | Protected IPA which is not associated with any Granule. |
| HIPAS_UNASSIGNED_NS | Unprotected IPA which is not associated with any Granule. |
19.14 RmmLfaPolicy type
The RmmLfaPolicy enumeration represents a Live Firmware Activation policy.
The RmmLfaPolicy enumeration is an abstract type.
The values of the RmmLfaPolicy enumeration are shown in the following table.
| Name | Description |
|---|---|
| LFA_ALLOW | LFA is permitted. |
| LFA_DISALLOW | LFA is not permitted. |
The RmmLfaPolicy enumeration is used in the following types:
19.15 RmmMeasurementDescriptorData type
The RmmMeasurementDescriptorData structure contains data structure used to calculate the contribution to the RIM of a DATA Granule.
The RmmMeasurementDescriptorData structure is a concrete type.
The width of the RmmMeasurementDescriptorData structure is 256
(0x100) bytes.
See also:
- Section 15.3.1.4
The members of the RmmMeasurementDescriptorData structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| desc_type | 0x0 |
Bits8 | Measurement descriptor type, value 0x0 |
| len | 0x8 |
UInt64 | Length of this data structure in bytes |
| rim | 0x10 |
RmmRealmMeasurement | Current RIM value |
| ipa | 0x50 |
Address | IPA at which the DATA Granule is mapped in the Realm |
| flags | 0x58 |
RmmDataFlags | Flags provided by Host |
| content | 0x60 |
RmmRealmMeasurement | Hash of contents of DATA Granule, or zero if flags indicate DATA Granule contents are unmeasured |
Unused bits of the RmmMeasurementDescriptorData structure MBZ.
19.16 RmmMeasurementDescriptorRec type
The RmmMeasurementDescriptorRec structure contains data structure used to calculate the contribution to the RIM of a REC.
The RmmMeasurementDescriptorRec structure is a concrete type.
The width of the RmmMeasurementDescriptorRec structure is 256
(0x100) bytes.
See also:
- Section 15.3.28.4
The members of the RmmMeasurementDescriptorRec structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| desc_type | 0x0 |
Bits8 | Measurement descriptor type, value 0x1 |
| len | 0x8 |
UInt64 | Length of this data structure in bytes |
| rim | 0x10 |
RmmRealmMeasurement | Current RIM value |
| content | 0x50 |
RmmRealmMeasurement | Hash of 4KB page which contains REC parameters data structure |
Unused bits of the RmmMeasurementDescriptorRec structure MBZ.
19.17 RmmMeasurementDescriptorRipas type
The RmmMeasurementDescriptorRipas structure contains data structure used to calculate the contribution to the RIM of a RIPAS change.
The RmmMeasurementDescriptorRipas structure is a concrete type.
The width of the RmmMeasurementDescriptorRipas structure is 256
(0x100) bytes.
See also:
- Section 15.3.41.4
The members of the RmmMeasurementDescriptorRipas structure are shown in the following table.
| Name | Byte offset | Type | Description |
|---|---|---|---|
| desc_type | 0x0 |
Bits8 | Measurement descriptor type, value 0x2 |
| len | 0x8 |
UInt64 | Length of this data structure in bytes |
| rim | 0x10 |
RmmRealmMeasurement | Current RIM value |
| base | 0x50 |
Address | Base IPA of the RIPAS change |
| top | 0x58 |
Address | Top IPA of the RIPAS change |
Unused bits of the RmmMeasurementDescriptorRipas structure MBZ.
19.18 RmmMecPolicy type
The RmmMecPolicy enumeration represents a MEC policy.
The RmmMecPolicy enumeration is an abstract type.
The values of the RmmMecPolicy enumeration are shown in the following table.
| Name | Description |
|---|---|
| MEC_POLICY_PRIVATE | The MEC protects memory owned by a single Realm. A MEC with this policy may be referred to as a Private MEC. |
| MEC_POLICY_SHARED | The MEC protects memory owned by multiple Realms. A MEC with this policy may be referred to as a Shared MEC. |
The RmmMecPolicy enumeration is used in the following types:
19.19 RmmMecState type
The RmmMecState enumeration represents state of a MEC.
The RmmMecState enumeration is an abstract type.
The values of the RmmMecState enumeration are shown in the following table.
| Name | Description |
|---|---|
| MEC_STATE_PRIVATE_ASSIGNED | A Private MEC which is assigned to a Realm. |
| MEC_STATE_PRIVATE_UNASSIGNED | A Private MEC which is not assigned to a Realm. |
| MEC_STATE_SHARED | A Shared MEC. |
19.20 RmmMemPermLocked type
The RmmMemPermLocked enumeration represents whether a memory permission value is locked.
The RmmMemPermLocked enumeration is an abstract type.
The values of the RmmMemPermLocked enumeration are shown in the following table.
| Name | Description |
|---|---|
| MEM_PERM_LOCKED | Memory permission value is locked |
| MEM_PERM_UNLOCKED | Memory permission value is unlocked |
The RmmMemPermLocked enumeration is used in the following types:
19.21 RmmMemPerms type
The RmmMemPerms structure contains memory permissions.
The RmmMemPerms structure is an abstract type.
The members of the RmmMemPerms structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| values | Bits64[16] | Mapping from memory permission index to memory permission label Values use architectural encodings. |
The RmmMemPerms structure is used in the following types:
19.22 RmmPdev type
The RmmPdev structure contains attributes of a PDEV.
The RmmPdev structure is an abstract type.
The members of the RmmPdev structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| pdev_id | Bits64 | Device identifier |
| prot_config | RmmPdevProtConfig | Configuration of protection between system and device |
| segment_id | Bits16 | Segment identifier PCIe Segment identifier of the Root Port and endpoint. |
| root_id | Bits16 | Root Port identifier Physical PCIe routing identifier of the Root Port to which the endpoint is connected. |
| cert_id | UInt64 | Certificate identifier |
| rid_base | UInt64 | Base of requester ID range (inclusive) |
| rid_top | UInt64 | Top of requester ID range (exclusive) |
| hash_algo | RmmHashAlgorithm | Algorithm used to generate device digests |
| ncoh_sidide_sid | UInt64 | IDE stream ID used to secure non-coherent traffic |
| ncoh_num_addr_rangeiocoh_num_addr_range | UInt64 | Number of nonIO-coherent address ranges |
| ncoh_addr_rangeiocoh_addr_range | RmmAddressRange[16] | NonIO-coherent address range |
| coh_sidfcoh_num_addr_range | UInt64 | Selective IDE stream identifier coh_num_addr_range UInt64Number of fully-coherent address ranges |
| coh_addr_rangefcoh_addr_range | RmmAddressRange[4] | CoherentFully-coherent address range |
| aux | Address[32] | Addresses of auxiliary Granules |
| num_aux | UInt64 | Number of auxiliary Granules |
| state | RmmPdevState | Lifecycle state |
| comm_state | RmmDevCommState | Device communication state |
| num_vdevs | UInt64 | Number of VDEVs associated with this PDEV whose state is not VDEV_STOPPED |
19.23 RmmPdevIdeRmmPdevProtConfig type
The RmmPdevIdeRmmPdevProtConfig enumeration represents whether the link to theconfiguration of protection between system and device is protected using IDE.
The RmmPdevIdeRmmPdevProtConfig enumeration is an abstract type.
The values of the RmmPdevIdeRmmPdevProtConfig enumeration are shown in the following table.
| Name | Description |
|---|---|
| IDE_FALSEPDEV_FCOH_E2E_IDE | The link to theFully-coherent device is not protected using with end-to-end protection provided by IDE. |
| IDE_TRUEPDEV_FCOH_E2E_SYS | The link to theFully-coherent device is protected usingwith end-to-end protection provided by system construction. |
| PDEV_IOCOH_E2E_IDE | IO-coherent device with end-to-end protection provided by IDE. |
| PDEV_IOCOH_E2E_SYS | IO-coherent device with end-to-end protection provided by system construction. |
The RmmPdevProtConfig enumeration is used in the following types:
19.24 RmmPdevProtConfigRmmPdevState type
The RmmPdevProtConfigRmmPdevState enumeration represents configuration of protection between system and devicethe state of a PDEV.
The RmmPdevProtConfigRmmPdevState enumeration is an abstract type.
The values of the RmmPdevProtConfigRmmPdevState enumeration are shown in the following table.
| Name | Description |
|---|---|
| PDEV_COH_E2EPDEV_COMMUNICATING | CoherentThe RMM is communicating with the device with end-to-end protection. |
| PDEV_COH_LINKPDEV_ERROR | Coherent device with link protectionDevice has reported a fatal error. |
| PDEV_NCOH_E2EPDEV_HAS_KEY | Non-coherentRMM has device with end-to-end protectionpublic key. |
| PDEV_IDE_RESETTING | The PDEV’s IDE link is being reset. |
| PDEV_NEEDS_KEY | RMM needs device public key. |
| PDEV_NEW | Initial state of the device. |
| PDEV_READY | Secure connection between the RMM and the device has been established. Physical link between the device and memory is secured. Ready for creation of VDEV instances. |
| PDEV_STOPPED | Secure connection between the RMM and the device has been terminated. |
| PDEV_STOPPING | The RMM is communicating with the device to terminate the secure connection between the RMM and the device. |
The RmmPdevState enumeration is used in the following types:
19.25 RmmPdevSpdm RmmPhysicalAddressSpace type
The RmmPdevSpdmRmmPhysicalAddressSpace enumeration represents whether communication between the RMM and the device uses SPDMthe PAS of a Granule.
The RmmPdevSpdmRmmPhysicalAddressSpace enumeration is an abstract type.
See also:
- Section 14.30
The values of the RmmPdevSpdmRmmPhysicalAddressSpace enumeration are shown in the following table.
| Name | Description |
|---|---|
| SPDM_FALSEPAS_NS | Communication between the RMM and the device does not use SPDMNon-secure PAS. |
| SPDM_TRUEPAS_REALM | Communication between the RMM and the device uses SPDMRealm PAS. |
| PAS_ROOT | Root PAS. |
| PAS_SECURE | Secure PAS. |
19.26 RmmPdevStateRmmPlaneRttFeature type
The RmmPdevStateRmmPlaneRttFeature enumeration represents the state of a PDEVRTT usage models supported for multi-Plane Realms.
The RmmPdevStateRmmPlaneRttFeature enumeration is an abstract type.
The values of the RmmPdevState enumeration are shown in the following table. Name Description PDEV_COMMUNICATING The RMM is communicating with the device. PDEV_ERROR Device has reported a fatal error. PDEV_HAS_KEY RMM has device public key. PDEV_IDE_RESETTING The PDEV’s IDE link is being reset. PDEV_NEEDS_KEY RMM needs device public key. PDEV_NEW Initial state of the device. PDEV_READY Secure connection between the RMM and the device has been established. Physical link between the device and memory is secured. Ready for creation of VDEV instances. PDEV_STOPPED Secure connection between the RMM and the device has been terminated. PDEV_STOPPING The RMM is communicating with the device to terminate the secure connection between the RMM and the device. 19.27 RmmPhysicalAddressSpace type The RmmPhysicalAddressSpace enumeration represents the PAS of a Granule. The RmmPhysicalAddressSpace enumeration is an abstract type.See also:
-
Section 14.29
The values of the RmmPhysicalAddressSpace enumeration are shown in
the following table.
Name
Description
PAS_NS
Non-secure PAS.
PAS_REALM
Realm PAS.
PAS_ROOT
Root PAS.
PAS_SECURE
Secure PAS.
19.28 RmmPlaneRttFeature type
The RmmPlaneRttFeature enumeration represents RTT usage models
supported for multi-Plane Realms.
The RmmPlaneRttFeature enumeration is an abstract type.
See also:
- Section 3.11
The values of the RmmPlaneRttFeature enumeration are shown in the following table.
| Name | Description |
|---|---|
| PLANE_RTT_AUX | A multi-Plane Realm uses auxiliary RTTs |
| PLANE_RTT_AUX_SINGLE | A multi-Plane Realm can be configured to either use auxiliary RTTs, or a single RTT |
| PLANE_RTT_SINGLE | A multi-Plane Realm uses a single RTT |
The RmmPlaneRttFeature enumeration is used in the following types:
19.27 RmmRdev type
The RmmRdev structure contains attributes of an RDEV.
The RmmRdev structure is an abstract type.
The members of the RmmRdev structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| state | RmmRdevState | Lifecycle state |
| operation | RmmRdevOperation | Operation being performed by the RDEV |
| vdev_ptr | Address | PA of VDEV associated with this RDEV |
19.28 RmmRdevOperation type
The RmmRdevOperation enumeration represents operation being performed by an RDEV.
The RmmRdevOperation enumeration is an abstract type.
The values of the RmmRdevOperation enumeration are shown in the following table.
| Name | Description |
|---|---|
| RDEV_OP_GET_INTERFACE_REPORT | RDEV is handling an RSI_RDEV_GET_INTERFACE_REPORT request. |
| RDEV_OP_GET_MEASUREMENTS | RDEV is handling an RSI_RDEV_GET_MEASUREMENTS request. |
| RDEV_OP_LOCK | RDEV is handling an RSI_RDEV_LOCK request. |
| RDEV_OP_NONE | No operation is being performed. |
| RDEV_OP_START | RDEV is handling an RSI_RDEV_START request. |
The RmmRdevOperation enumeration is used in the following types:
19.29 RmmRdevRmmRdevState type
The RmmRdev structure contains attributesRmmRdevState enumeration represents the state of an RDEV.
The RmmRdev structure is an RmmRdevState enumeration is an abstract type.
The members of the RmmRdev structurevalues of the RmmRdevState enumeration are shown in the following table.
| Name | TypeDescription |
|---|---|
| stateRDEV_ERROR | Device interface has reported a fatal error. |
| RDEV_LOCKED | Device interface is locked. |
| RDEV_LOCKED_BUSY | Device interface is locked and is handling an interruptible Realm device operation. |
| RDEV_NEW | Device interface is unlocked. |
| RDEV_NEW_BUSY | Device interface is unlocked and is handling an interruptible Realm device operation. |
| RDEV_STARTED | Device interface is started. |
| RDEV_STARTED_BUSY | Device interface is started and is handling an interruptible Realm device operation. |
| RDEV_STOPPED | Device interface is stopped. |
| RDEV_STOPPING | Device interface is stopping. |
The RmmRdevState enumeration is used in the following types:
- RmmRdev Lifecycle state operation RmmRdevOperation Operation being performed by the RDEV vdev_ptr Address PA of VDEV associated with this RDEV
19.30 RmmRdevOperationRmmRealm type
The RmmRdevOperation enumeration represents operation being performed by an RDEVRmmRealm structure contains attributes of a Realm.
The RmmRdevOperation enumeration is an RmmRealm structure is an abstract type.
The values of the RmmRdevOperation enumeration are shown in the following table. Name Description RDEV_OP_GET_INTERFACE_REPORT RDEV is handling an RSI_RDEV_GET_INTERFACE_REPORT request. RDEV_OP_GET_MEASUREMENTS RDEV is handling an RSI_RDEV_GET_MEASUREMENTS request. RDEV_OP_LOCK RDEV is handling an RSI_RDEV_LOCK request. RDEV_OP_NONE No operation is being performed. RDEV_OP_START RDEV is handling an RSI_RDEV_START request. 19.31 RmmRdevState type The RmmRdevState enumeration represents the state of an RDEV. The RmmRdevState enumeration is an abstract type. The values of the RmmRdevState enumeration are shown in the following table. Name Description RDEV_ERROR Device interface has reported a fatal error. RDEV_LOCKED Device interface is locked. RDEV_LOCKED_BUSY Device interface is locked and is handling an interruptible Realm device operation. RDEV_NEW Device interface is unlocked. RDEV_NEW_BUSY Device interface is unlocked and is handling an interruptible Realm device operation. RDEV_STARTED Device interface is started. RDEV_STARTED_BUSY Device interface is started and is handling an interruptible Realm device operation. RDEV_STOPPED Device interface is stopped. RDEV_STOPPING Device interface is stopping. 19.32 RmmRealm type The RmmRealm structure contains attributes of a Realm. The RmmRealm structure is an abstract type.See also:
- Section 2.1
The members of the RmmRealm structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| feat_lpa2 | RmmFeature | Whether LPA2 is enabled for this Realm |
| ipa_width | UInt8 | IPA width in bits |
| measurements | RmmRealmMeasurement[5] | Realm measurements |
| hash_algo | RmmHashAlgorithm | Algorithm used to compute Realm measurements |
| rec_index | UInt64 | Index of next REC to be created |
| rtt_base | Address[4] | Realm Translation Table base addresses If rtt_tree_pp is FEATURE_FALSE then only the first entry is valid. If rtt_tree_pp is FEATURE_TRUE then only the first (num_aux_planes + 1) entries are valid. |
| rtt_level_start | Int64 | RTT starting level |
| rtt_num_start | UInt64 | Number of physically contiguous starting level RTTs |
| state | RmmRealmState | Lifecycle state |
| vmid | Bits16[4] | Virtual Machine Identifiers If rtt_tree_pp is FEATURE_FALSE then only the first entry is valid. If rtt_tree_pp is FEATURE_TRUE then only the first (num_aux_planes + 1) entries are valid. |
| rpv | Bits512 | Realm Personalization Value |
| feat_da | RmmFeature | Whether Realm device assignment is enabled for this Realm |
| rtt_tree_pp | RmmFeature | Whether this Realm has an RTT per Plane |
| num_aux_planes | UInt64 | Number of auxiliary Planes |
| overlay_perms | RmmMemPerms[4] | Memory overlay permissions |
| overlay_locked | RmmMemPermLocked[16] | Whether memory overlay value is locked |
| lfa_policy | RmmLfaPolicy | Live Firmware Activation policy for components within the Realm’s TCB |
| mecid | Bits64 | Memory Encryption Context Identifier |
| mec_policy | RmmMecPolicy | MEC policy |
| num_recs | UInt64 | Number of RECs owned by this Realm |
| num_vdevs | UInt64 | Number of VDEVs which have been assigned to this Realm |
19.31 RmmRealmMeasurement type
The RmmRealmMeasurement type is realm measurement.
The RmmRealmMeasurement type is a concrete type.
The width of the RmmRealmMeasurement type is 512 bits.
19.32 RmmRealmState type
The RmmRealmState enumeration represents the state of a Realm.
The RmmRealmState enumeration is an abstract type.
The values of the RmmRealmState enumeration are shown in the following table.
| Name | Description |
|---|---|
| REALM_ACTIVE | Eligible for execution. |
| REALM_NEW | Under construction. Not eligible for execution. |
| REALM_SYSTEM_OFF | System has been turned off. Not eligible for execution. |
The RmmRealmState enumeration is used in the following types:
19.33 RmmRealmMeasurementRmmRec type
The RmmRealmMeasurement type is realm measurementRmmRec structure contains attributes of a REC.
The RmmRealmMeasurement type is aRmmRec structure is an concreteabstract type.
The width of the RmmRealmMeasurement type is 512 bits. 19.34 RmmRealmState type The RmmRealmState enumeration represents the state of a Realm. The RmmRealmState enumeration is an abstract type. The values of the RmmRealmState enumeration are shown in the following table. Name Description REALM_ACTIVE Eligible for execution. REALM_NEW Under construction. Not eligible for execution. REALM_SYSTEM_OFF System has been turned off. Not eligible for execution. 19.35 RmmRec type The RmmRec structure contains attributes of a REC. The RmmRec structure is an abstract type.See also:
- Section 2.3
The members of the RmmRec structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| attest_state | RmmRecAttestState | Attestation token generation state |
| attest_challenge | Bits512 | Challenge for under-construction attestation token |
| aux | Address[16] | Addresses of auxiliary Granules |
| emulatable_abort | RmmRecEmulatableAbort | Whether the most recent exit from this REC was due to an Emulatable Data Abort |
| flags | RmmRecFlags | Flags which control REC behavior |
| gprs | Bits64[32] | General-purpose register values |
| mpidr | Bits64 | MPIDR value |
| owner | Address | PA of RD of Realm which owns this REC |
| pc | Bits64 | Program counter value |
| pending | RmmRecPending | Whether a REC operation is pending |
| vdev_id | Bits64 | Virtual device ID |
| inst_id | UInt64 | Device instance ID |
| inst_id_valid | RmmBoolean | Whether device instance ID is valid |
| state | RmmRecState | Lifecycle state |
| sysregs | RmmSystemRegisters | EL1 and EL0 system register values |
| ripas_addr | Address | Next address to be processed in RIPAS change |
| ripas_top | Address | Top address of pending RIPAS change |
| ripas_value | RmmRipas | RIPAS value of pending RIPAS change |
| ripas_destroyed | RmmRipasChangeDestroyed | Whether a RIPAS change from DESTROYED should be permitted |
| ripas_response | RmmRecResponse | Host response to RIPAS change request |
| ripas_dev_pa | Address | Base PA of device memory region, if RIPAS change is pending due to exection of RSI_RDEV_VALIDATE_MAPPING |
| ripas_dev_shared | RmmDevMemShared | Value of shared bit, if RIPAS change is pending due to exection of RSI_RDEV_VALIDATE_MAPPING |
| s2ap_addr | Address | Next address to be processed in S2AP change |
| s2ap_top | Address | Top address of pending S2AP change |
| s2ap_overlay | UInt3 | Overlay index of pending S2AP change |
| s2ap_response | RmmRecResponse | Host response to S2AP change request |
| gic_owner | UInt64 | Index of Plane which is the GIC owner |
19.34 RmmRecAttestState type
The RmmRecAttestState enumeration represents whether an attestation token generation operation is ongoing on this REC.
The RmmRecAttestState enumeration is an abstract type.
The values of the RmmRecAttestState enumeration are shown in the following table.
| Name | Description |
|---|---|
| ATTEST_IN_PROGRESS | An attestation token generation operation is in progress. |
| NO_ATTEST_IN_PROGRESS | No attestation token generation operation is in progress. |
The RmmRecAttestState enumeration is used in the following types:
19.35 RmmRecEmulatableAbort type
The RmmRecEmulatableAbort enumeration represents whether the most recent exit from a REC was due to an Emulatable Data Abort.
The RmmRecEmulatableAbort enumeration is an abstract type.
The values of the RmmRecEmulatableAbort enumeration are shown in the following table.
| Name | Description |
|---|---|
| EMULATABLE_ABORT | The most recent exit from a REC was due to an Emulatable Data Abort. |
| NOT_EMULATABLE_ABORT | The most recent exit from a REC was not due to an Emulatable Data Abort. |
The RmmRecEmulatableAbort enumeration is used in the following types:
19.36 RmmRecAttestStateRmmRecFlags type
The RmmRecAttestState enumeration represents whether an attestation token generation operation is ongoing on thisRmmRecFlags structure contains REC flags.
The RmmRecAttestState enumeration is an RmmRecFlags structure is an abstract type.
The values of the RmmRecAttestState enumerationmembers of the RmmRecFlags structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| ATTEST_IN_PROGRESSrunnable | An attestation token generation operation is in progress.RmmRecRunnable | Whether the REC is elgible to run |
The RmmRecFlags structure is used in the following types:
19.37 RmmRecEmulatableAbort RmmRecPending type
The RmmRecEmulatableAbortRmmRecPending enumeration represents whether the most recent exit from a REC was due to an Emulatable Data Abortoperation is pending.
The RmmRecEmulatableAbortRmmRecPending enumeration is an abstract type.
The values of the RmmRecEmulatableAbortRmmRecPending enumeration are shown in the following table.
| Name | Description |
|---|---|
| EMULATABLE_ABORTREC_PENDING_HOST_CALL | The most recent exit from a REC was due to an Emulatable Data AbortA Host call is pending. |
| NOT_EMULATABLE_ABORTREC_PENDING_NONE | The most recent exit from a REC was not due to an Emulatable Data AbortNo operation is pending. |
| REC_PENDING_PSCI | A PSCI operation is pending. |
| REC_PENDING_VDEV_REQUEST | A VDEV request is pending. |
The RmmRecPending enumeration is used in the following types:
19.38 RmmRecFlagsRmmRecResponse type
The RmmRecFlags structure contains REC flagsRmmRecResponse enumeration represents whether the Host accepted or rejected a Realm request.
The RmmRecFlags structure is an RmmRecResponse enumeration is an abstract type.
The members of the RmmRecFlags structurevalues of the RmmRecResponse enumeration are shown in the following table.
| Name | Description |
|---|---|
| ACCEPT | Host accepted the Realm request. |
| REJECT | Host rejected the Realm request. |
The RmmRecResponse enumeration is used in the following types:
19.39 RmmRecRunnable type
The RmmRecRunnable enumeration represents whether a REC is eligible for execution.
The RmmRecRunnable enumeration is an abstract type.
The values of the RmmRecRunnable enumeration are shown in the following table.
| Name | Description |
|---|---|
| NOT_RUNNABLE | Not eligible for execution. |
| RUNNABLE | Eligible for execution. |
The RmmRecRunnable enumeration is used in the following types:
19.40 RmmRecState type
The RmmRecState enumeration represents the state of a REC.
The RmmRecState enumeration is an abstract type.
The values of the RmmRecState enumeration are shown in the following table.
| Name | Description |
|---|---|
| REC_READY | REC is not currently running. |
| REC_RUNNING | REC is currently running. |
The RmmRecState enumeration is used in the following types:
19.41 RmmRipas type
The RmmRipas enumeration represents realm IPA state.
The RmmRipas enumeration is an abstract type.
The values of the RmmRipas enumeration are shown in the following table.
| Name | Description |
|---|---|
| DESTROYED | Address which is inaccessible to the Realm due to an action taken by the Host. |
| DEV | Address where memory of an assigned Realm device is mapped. |
| EMPTY | Address where no Realm resources are mapped. |
| RAM | Address where private code or data owned by the Realm is mapped. |
The RmmRipas enumeration is used in the following types:
19.42 RmmRipasChangeDestroyed type
The RmmRipasChangeDestroyed enumeration represents whether a RIPAS change from DESTROYED should be permitted.
The RmmRipasChangeDestroyed enumeration is an abstract type.
The values of the RmmRipasChangeDestroyed enumeration are shown in the following table.
| Name | Description |
|---|---|
| CHANGE_DESTROYED | A RIPAS change from DESTROYED should be permitted. |
| NO_CHANGE_DESTROYED | A RIPAS change from DESTROYED should not be permitted. |
The RmmRipasChangeDestroyed enumeration is used in the following types:
19.43 RmmRtt type
The RmmRtt structure contains an RTT.
The RmmRtt structure is an abstract type.
The members of the RmmRtt structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| entries | RmmRttEntry[512] | Entries |
19.4644 RmmRttEntry type
The RmmRttEntry structure contains attributes of an RTT Entry.
The RmmRttEntry structure is an abstract type.
See also:
- Section 5.5
The members of the RmmRttEntry structure are shown in the following table.
The RmmRttEntry structure is used in the following types:
19.45 RmmRttEntryState type
The RmmRttEntryState enumeration represents the state of an RTTE.
The RmmRttEntryState enumeration is an abstract type.
The values of the RmmRttEntryState enumeration are shown in the following table.
| Name | Description |
|---|---|
| ASSIGNED | This RTTE is identified by a Protected IPA. The output address of this RTTE points to a DATA Granule. |
| ASSIGNED_DEV_PRIVATE | This RTTE is identified by a Protected IPA. The output address of this RTTE points to a DEV_PRIVATE Granule. |
| ASSIGNED_DEV_SHARED | This RTTE is identified by a Protected IPA. The output address of this RTTE points to a DEV_SHARED Granule. |
| ASSIGNED_NS | This RTTE is identified by an Unprotected IPA. The output address of this RTTE points to an NS Granule. |
| AUX_DESTROYED | An auxiliary RTT was destroyed while a corresponding primary RTT entry was live. |
| TABLE | The output address of this RTTE points to the next-level RTT. |
| UNASSIGNED | This RTTE is identified by a Protected IPA. This RTTE is not associated with any Granule. |
| UNASSIGNED_NS | This RTTE is identified by an Unprotected IPA. This RTTE is not associated with any Granule. |
The RmmRttEntryState enumeration is used in the following types:
19.46 RmmRttWalkNotAligned type
The RmmRttWalkNotAligned structure contains result of an RTT walk which is not aligned to the requested level.
The RmmRttWalkNotAligned structure is an abstract type.
The members of the RmmRttWalkNotAligned structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| valid | RmmBoolean | TRUE if an RTT walk was performed whose result is not aligned to the requested level |
| index | UInt64 | RTT index |
| addr | Address | Address |
| walk | RmmRttWalkResult | Walk result |
19.47 RmmRttEntryStateRmmRttWalkResult type
The RmmRttEntryState enumeration represents the state of an RTTERmmRttWalkResult structure contains result of an RTT walk.
The RmmRttEntryState enumeration is an RmmRttWalkResult structure is an abstract type.
The values of the RmmRttEntryState enumeration are shown in the following table. Name Description ASSIGNED This RTTE is identified by a Protected IPA. The output address of this RTTE points to a DATA Granule. ASSIGNED_DEV_PRIVATE This RTTE is identified by a Protected IPA. The output address of this RTTE points to a DEV_PRIVATE Granule. ASSIGNED_DEV_SHARED This RTTE is identified by a Protected IPA. The output address of this RTTE points to a DEV_SHARED Granule. ASSIGNED_NS This RTTE is identified by an Unprotected IPA. The output address of this RTTE points to an NS Granule. AUX_DESTROYED An auxiliary RTT was destroyed while a corresponding primary RTT entry was live. TABLE The output address of this RTTE points to the next-level RTT. UNASSIGNED This RTTE is identified by a Protected IPA. This RTTE is not associated with any Granule. UNASSIGNED_NS This RTTE is identified by an Unprotected IPA. This RTTE is not associated with any Granule. 19.48 RmmRttWalkResult type The RmmRttWalkResult structure contains result of an RTT walk. The RmmRttWalkResult structure is an abstract type.See also:
- Section 5.5.10
The members of the RmmRttWalkResult structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| level | Int8 | RTT level reached by the walk |
| rtt_addr | Address | Address of RTT reached by the walk |
| rtte | RmmRttEntry | RTTE reached by the walk |
The RmmRttWalkResult structure is used in the following types:
19.48 RmmSystemRegisters type
The RmmSystemRegisters structure contains EL0 and EL1 system registers.
The RmmSystemRegisters structure is an abstract type.
The RmmSystemRegisters structure is used in the following types:
19.49 RmmRttWalkResultsRmmVdev type
The RmmRttWalkResults typeRmmVdev structure contains results of RTT walks across all RTT treesattributes of a VDEV.
The RmmRttWalkResults typeRmmVdev structure is an abstract type.
The RmmRttWalkResults type is an array of 4 elements of type RmmRttWalkResult. 19.50 RmmSystemRegisters type The RmmSystemRegistersmembers of the RmmVdev structure contains EL0 and EL1 system registers. The RmmSystemRegisters structure is an abstract type. 19.51 RmmVdev type The RmmVdev structure contains attributes of a VDEV. The RmmVdev structure is an abstract type. The members of the RmmVdev structure are shown in the following table.
| Name | Type | Description |
|---|---|---|
| vdev_id | Bits64 | Virtual device identifier |
| tdi_id | Bits64 | TDI identifier |
| inst_id | UInt64 | Instance identifier |
| pdev | Address | PA of parent PDEV |
| realm | Address | PA of RD of Realm which owns this REC |
| state | RmmVdevState | Lifecycle state |
| comm_state | RmmDevCommState | Device communication state |
| aux | Address[32] | Addresses of auxiliary Granules |
| num_aux | UInt64 | Number of auxiliary Granules |
19.5250 RmmVdevState type
The RmmVdevState enumeration represents the state of a VDEV.
The RmmVdevState enumeration is an abstract type.
The values of the RmmVdevState enumeration are shown in the following table.
| Name | Description |
|---|---|
| VDEV_COMMUNICATING | The RMM is communicating with the VDEV. |
| VDEV_ERROR | Device interface has reported a fatal error. |
| VDEV_READY | No device transaction is associated with the VDEV. |
| VDEV_STOPPED | Device interface is stopped. |
| VDEV_STOPPING | The RMM is communicating with the VDEV to stop the device interface. |
The RmmVdevState enumeration is used in the following types:
20 Generic types
This section defines types which are shared between RMM interfaces and descriptions of RMM abstract state.
20.1 Address type
The Address type is an address.
The Address type is a concrete type.
The width of the Address type is 64 bits.
20.2 BitsN type
The BitsN type is an N-bit field.
The BitsN type is a concrete type.
The width of the BitsN type is N bits.
20.3 IntN type
The IntN type is an signed N-bit integer.
The IntN type is a concrete type.
The width of the IntN type is N bits.
20.4 UIntN type
The UIntN type is an unsigned N-bit integer.
The UIntN type is a concrete type.
The width of the UIntN type is N bits.
21 Flows
This section presents flows which explain how the RMM architecture can be used by the Host, and by Realm software.
Note that parts of the sequences below are for illustration only. For example, in the Realm creation flows, the RMI_GRANULE_DELEGATE and RMI_GRANULE_UNDELEGATE commands are called immediately before or after the RMI_X_CREATE and RMI_X_DESTROY commands respectively. An alternative flow would be for the Host to maintain a pool of Granules in the DELEGATED state, from which RMM data structures and Realm data can be allocated on demand.
21.1 Granule delegation flows
21.1.1 Granule delegation flow
The following diagram shows how the GPT entry of a Granule is changed to GPT_REALM.
See Arm Architecture Reference Manual Supplement, The Realm Management Extension (RME), for Armv9-A [2] for example software flows for the operations performed by the Monitor in this flow.
It is anticipated that the Monitor software will be required to use synchronization mechanisms to serialize access to the GPT.
21.1.2 Granule undelegation flow
The following diagram shows how the GPT entry of a Granule is changed from GPT_REALM.
See Arm Architecture Reference Manual Supplement, The Realm Management Extension (RME), for Armv9-A [2] for example software flows for the operations performed by the Monitor in this flow.
It is anticipated that the Monitor software will be required to use synchronization mechanisms to serialize access to the GPT.
21.2 Realm lifecycle flows
This section contains flows which relate to the Realm lifecycle.
See also:
- Section 2.1.5
21.2.1 Realm creation flow
The following diagram shows the flow for creating a Realm.
To create a Realm, the Host must allocate and delegate two Granules:
rdto store the Realm Descriptorrttwhich will be the starting level Realm Translation Table (RTT)
The Host also provides an NS Granule (params) containing
Realm creation parameters.
21.2.2 Realm Translation Table creation flow
The following diagram shows the flow for populating the Realm Translation Tables (RTTs).
The starting level Realm Translation Tables (RTTs) are provided at Realm creation time.
Subsequent levels of RTT are added using the RMI_RTT_CREATE command. This can be performed when the state of the Realm is REALM_NEW or REALM_ACTIVE.
21.2.3 Initialize memory of New Realm flow
Immediately following Realm creation, every page in the Protected IPA space has its RIPAS set to EMPTY. There are two ways in which the Host can set the RIPAS of a given page of Protected IPA space to RAM:
Change the RIPAS by executing RMI_RTT_INIT_RIPAS, but do not populate the contents of the page. The RIM is extended to reflect the RIPAS change.
Both change the RIPAS and populate the page with contents provided by the Host, by executing RMI_DATA_CREATE. The RIM is extended to reflect the contents added by the Host.
Once the Host has performed either of these actions for a given page of Protected IPA space, that page cannot be further modified prior to Realm activation.
The following diagram shows the flow for initializing the RIPAS without providing contents.
The following diagram shows the flow for populating the page with contents provided by the Host.
To do this, the Host must:
- Delegate a destination Granule (
dst). - Provide an NS Granule (
src), whose contents will be copied into the destination Granule. - Specify the Protected IPA
ipaat which thedstGranule should be mapped in the Realm’s IPA space. - Ensure that the level 3 RTT which contains the RTTE identified by the Protected IPA has been created.
Once the Data Granule has been created, the src Granule
can be reallocated by the Host.
See also:
21.2.4 REC creation flow
The following diagram shows the flow for creating a REC during Realm creation.
To create a REC, the Host must:
- Delegate a destination Granule (
rec). - Query the number of auxiliary Granules required, by calling RMI_REC_AUX_COUNT
- Delegate the required number of auxiliary Granules
(
aux) - Provide auxiliary Granule addresses, register values and REC
activation status in an NS Granule (
params).
Once the REC has been created, the params Granule can be
reallocated by the Host.
21.2.5 Realm destruction flow
The following diagram shows the flow for destroying a Realm.
To destroy a Realm, the Host must first make the Realm non-live. This is done by destroying (in any order) the objects which are associated with the Realm:
- Data Granules
- RECs
- RTTs
Finally, the Realm itself can be destroyed.
Once each of these objects has been destroyed, the corresponding Granules can be undelegated and reallocated by the Host.
See also:
21.3 Realm exception model flows
This section contains flows which relate to the Realm exception model.
See also:
- Section 4
21.3.1 Realm entry and exit flow
The following diagram shows how a Realm is executed, and illustrates the different reasons for exiting the Realm and returning control to the Host.
A REC is entered using the RMI_REC_ENTER command. The parameters to this command include:
- an RmiRecEnter object, which is a data structure used to pass values from the Host to the RMM on REC entry
- an RmiRecExit object, which is a data structure used to pass values from the RMM to the Host on REC exit
21.3.2 Host call flow
The following diagram shows how software executing inside the Realm can voluntarily yield control back to the Host by making a Host call.
A REC is entered using the RMI_REC_ENTER command. The parameters to this command include:
- an RmiRecEnter object, which is a data structure used to pass values from the Host to the RMM on REC entry
- an RmiRecExit object, which is a data structure used to pass values from the RMM to the Host on REC exit
On execution of RSI_HOST_CALL, arguments are copied from the RsiHostCall object in Realm memory into the RmiRecExit object in NS memory. On the subsequent RMI_REC_ENTER, return values are copied from the RmiRecEnter object in NS memory into the RsiHostCall object in Realm memory.
See also:
- Section 4.5
21.3.3 REC exit due to Data Abort fault flow
The following diagram shows how a Data Abort due to a Realm access is taken to the Host.
A REC is entered using the RMI_REC_ENTER command. The parameters to this command include:
- an RmiRecEnter object, which is a data structure used to pass values from the Host to the RMM on REC entry
- an RmiRecExit object, which is a data structure used to pass values from the RMM to the Host on REC exit
See also:
- Section 4
21.3.4 MMIO emulation flow
The following diagram shows how an MMIO access by a Realm can be emulated by the Host.
See also:
- Section 4
21.4 PSCI flows
21.4.1 PSCI_CPU_ON flow
The following diagram shows how one Realm VPE can set the “runnable” flag in another Realm VPE by executing PSCI_CPU_ON.
21.5 Realm memory management flows
This section contains flows which relate to management of Realm memory.
See also:
- Section 5
21.5.1 Add memory to Active Realm flow
The following diagram shows the flow for adding memory to a Realm whose state is REALM_ACTIVE.
To add memory to a Realm whose state is REALM_ACTIVE, the Host must:
- Delegate a destination Granule (
dst). - Specify the Protected IPA at which the
dstGranule will be mapped in the Realm’s IPA space. - Ensure that the level 3 RTT which contains the RTTE identified by the Protected IPA has been created.
Once a given Protected IPA has been populated with unknown content, it cannot be repopulated.
21.5.2 NS memory flow
The following diagram describes how NS memory can be mapped into a Realm.
21.5.3 RIPAS change flow
The following diagram describes how a Realm requests a RIPAS change, and how that request is handled by the Host.
- The Realm calls RSI_IPA_STATE_SET to request a RIPAS change for IPA
range
[base, top). - This causes a REC exit due to RIPAS change pending.
On taking a REC exit due to RIPAS change pending, the Host does the following:
- Reads the region base and top addresses from the RmiRecExit object.
- Applies the requested RIPAS change to an IPA range starting from the base of the target region, and extending no further than the top of the target region.
- Calls RMI_REC_ENTER to re-enter the REC.
The Realm observes in X1 the top of the region for which the RIPAS change was applied.
21.5.4 S2AP change flow
The following diagram describes how a Realm requests a S2AP change, and how that request is handled by the Host.
- The Realm calls RSI_MEM_SET_PERM_INDEX to request an S2AP change for
IPA range
[base, top). - This causes a REC exit due to S2AP change pending.
On taking a REC exit due to S2AP change pending, the Host does the following:
- Reads the region base and top addresses from the RmiRecExit object.
- Applies the requested S2AP change to an IPA range starting from the base of the target region, and extending no further than the top of the target region.
- Calls RMI_REC_ENTER to re-enter the REC.
The Realm observes in X1 the top of the region for which the S2AP change was applied.
21.6 Realm interrupts and timers flows
21.6.1 Interrupt flow
The following diagram shows how a virtual interrupt is injected into a Realm by the Host.
See also:
- Section 6.1
21.6.2 Timer interrupt delivery flow
The following diagram shows how a timer interrupt is delivered to and handled by a Realm.
See also:
- Section 6.2
21.7 Realm attestation flows
21.7.1 Attestation token generation flow
The following diagram shows the flow for a Realm to obtain an attestation token.
The Realm first calls RSI_ATTESTATION_TOKEN_INIT, providing a challenge value. The output values include an upper bound on the attestation token size.
The Realm then calls RSI_ATTESTATION_TOKEN_CONTINUE, providing the address of a buffer where the next part of the attestation token will be written. This command is called in a loop, until the result is not RSI_INCOMPLETE.
21.7.2 Handling interrupts during attestation token generation flow
The following diagram shows how interrupts are handled during generation of an attestation token.
If the RMM detects that a physical interrupt is pending during execution of RSI_ATTESTATION_TOKEN_CONTINUE, it saves the execution context to the REC object, and performs a REC exit due to IRQ.
During handling of the IRQ, the Host may signal a virtual interrupt to the REC.
On the next entry to the REC, if a virtual interrupt is pending, it is taken to the REC’s exception vector.
Whether or not a virtual interrupt was taken, on return to the original thread, the REC determines that X0 is RSI_INCOMPLETE, and therefore calls RSI_ATTESTATION_TOKEN_CONTINUE again.
21.8 Realm device assignment flows
See Section 9.
22 Realm shared memory protocol
This section describes a protocol for management of memory which is shared between a Realm and the Host. This protocol makes use of the primitives described in this specification. However, the protocol itself is not part of the RMM architecture. Use of this protocol is subject to a contract between the Realm and Host software agents.
See also:
- Section 5
22.1 Realm shared memory protocol description
The Host agrees to provide the Realm with a certain amount of memory. This memory is referred to below as the Realm’s “memory footprint”.
The memory footprint is described to the Realm, for example via firmware tables. The Realm can choose, at any point during its execution, how much of its memory footprint is protected (accessible only to the Realm) and how much is shared with the Host.
Realm software treats the most significant IPA bit as a “protection
attribute” bit. This means that for every Protected IPA (in which the
most significant bit is '0'), there exists a corresponding
Unprotected IPA alias, which is generated by setting the most
significant bit to '1'.
The choice of whether a given page is protected or shared at a given time is expressed by setting the RIPAS of the Protected IPA:
- If the RIPAS of the Protected IPA is RAM, the page is protected and access to the Unprotected IPA alias causes a Synchronous External Abort taken to the Realm.
- If the RIPAS of the Protected IPA is EMPTY, the page is shared and access to the Unprotected IPA alias does not cause a Synchronous External Abort taken to the Realm.
The initial RIPAS for every page in the Realm’s memory footprint is described to the Realm, for example via firmware tables. The Host agrees that during Realm execution, it will accept a RIPAS change request on any page within the Realm’s memory footprint.
22.2 Realm shared memory protocol flow
The following diagram illustrates how the protocol is used to set up and tear down a shared memory buffer.
See also:
- Section 21.5.3
Glossary
ASL
Language used to express pseudocode implementations. Formal language definition can be found in Arm Specification Language Reference Manual [17].
CBOR
CCA
CCA platform
CDDL
COSE
DOE
DSM
EAT
ECAM
FAL
FID
GIC
See Arm Generic Interrupt Controller (GIC) Architecture Specification version 3 and version 4 [6]
GPF
GPT
Table which determines the Physical Address Space of each Granule.
HIPAS
Host
IAK
IDE
See PCI Express 6.0 specification [14]
IPA
Address space visible to software executing at EL1 in the Realm.
IPI
IRI
A subset of the components which make up the GIC.
ITS
A service provided by the GIC.
LFA
MBZ
MEC
MECID
MMIO
MPIDR
NS
PAS
PDEV
Object which represents a communication channel between the RMM and a physical device, for example a PCIe device.
PE
PMU
PSCI
See Arm Power State Coordination Interface (PSCI) [22]
RAK
RD
Object which stores attributes of a Realm.
RDEV
Object which represents Realm view of an assigned device
Realm
REC
Object which stores PE state associated with a thread of execution within a Realm.
REM
RHA
RIM
RIPAS
RME
RMI
RMM
RNVS
RPV
RSI
RTT
Object which describes the IPA space of a Realm.
RTTE
SBZ
SEA
SGI
SMCCC
See Arm SMC Calling Convention [16]
SPDM
See Security Protocol and Data Model (SPDM) [18] and Secured Messages using SPDM Specification version 1.1.0 [15]
SPM
TA
TOS
TSM
See Section 9
VDEV
Object which represents the binding between a device function and a Realm.
VMM
VMSA
VPE
Wiping