:imagesdir: ./images

[[refarch]]
== Reference Architecture Details

We describe the capabilities of the platform to support memory isolation
requirements for confidentiality of workloads in TVMs. We then describe
the properties of the TSM, its instantiation, isolation and operational model
for the TVM life cycle. The description in this section refers to the reference
architecture in Figure 1.

=== CoVE Memory Isolation

Memory isolation for TVMs is orchestrated by the TSM-driver and the TSM in two
phases: the conversion of memory to confidential memory and the assignment of
confidential memory (alongwith the enforcement of properties on use) to TVMs.
To enforce isolation across Host and Confidential supervisor domains, CoVE
requires isolation of physical memory (that supports paging when enabled). There
are two deployment models possible here. CoVE ABI is equally applicable for both
modes - this specification focusses on the second deployment model (b) where a
peer supervisor domain is used to host confidential workloads.

a. When the TSM is the only root HS mode component on the platform, the G-stage
page table can be used to enforce isolation between confidential TVMs and
ordinary VMs. In this model the host VMM must execute in the de-privileged VS
mode and the TSM must provide nested virtualization of the H-extension controls.
This model may be suitable for client/embedded systems.

b. The TSM operates in S/HS mode as a peer supervisor domain manager to the
hosting supervisor domain which operates in S/HS mode as well. This model uses
the MTT along with G-stage PT for confidential TVM isolation (where 1st
stage PT is used by the Guest OS normally). The MTT
is used to assign physical memory to the Confidential supervisor domain called
*Confidential* memory and memory accessible to the hosting supervisor domain
called *Non-Confidential*. MTT allows dynamic programming of the per-domain
access permissions. A TVM and/or TSM needs to access both types of memory:

* Confidential memory - used for TVM code, data
* Non-confidential memory - used for communication between TVM and the non-TCB
host software and/or non-TCB IO devices.

The TSM COVH ABI provides interfaces to the OS/VMM to convert / donate
memory from the hosting supervisor domain to the confidential supervisor domain.
Similarly, a separate ABI intrinsic is used to reclaim memory back from the
confidential supervisor domain to the hosting supervisor domain. Once physical
memory is converted to confidential - it is accessible only to the confidential
supervisor domain. By default, TVM memory is assigned by the TSM (which
operates in the confidential supervisor domain context) from confidential
physical memory regions. Note that a TVM may be assigned non-confidential
(shared) memory regions as well explicitly under the TVMs control. The TSM
manages the type and accessibility of all memory assigned to the TVM, to
mitigate attacks from non-TCB software. The TSM enforces isolation between TVMs
by using the G-stage page table.

* Hart operating with the confidential supervisor domain context has MTT
permissions to access Confidential and Non-confidential memory
* Hart not operating in a Confidential supervisor domain has access permissions
only for Non-confidential memory

[caption="Figure {counter:image}: ", reftext="Figure {image}"]
[title= "Confidential memory conversion"]
image::img_7.png[]

[NOTE]
====
To also provide physical memory protection, memory accessible to the
confidential supervisor domain via MTT may also be associated with a unique
memory encryption key. Additionally each TVM may also be associated with a
unique memory encryption key. These additional protection aspects are platform
and implementation dependent.
====

Confidential and non-confidential memory are both always assigned by the VMM -
the TSM and TSM-driver are expected to manage the isolation for confidential
memory by programming the Memory Tracking Table (MTT). The desired security
properties of memory tracking are discussed below. The TSM manages
finer-granular (page-based) allocation from confidential memory regions
(enforced by the memory tracking hardware) using the G-stage page table.

Four aspects of memory isolation are impacted due to this dynamic configurable
property of the MTT:

==== Address Translation/Page Walk
The figure 2 below describes a reference model for memory tracking lookup where
the physical address derived from the two-stage address translation and
protection mechanism is looked up via the MTT configured for the active
supervisor domain to get the access permissions for the physical address. This
lookup should be performed for each implicit and explicit memory access and per
the paging sizes/modes supported by the hart.

[caption="Figure {counter:image}: ", reftext="Figure {image}"]
[title= "Memory Tracking for Supervisor Domains"]
image::img_8.png[]

==== Management of isolation for Confidential Physical Memory

The SW TCB (TSM) manages the assignment of physical memory to the Confidential
supervisor domain, while the HW TCB (hart MMU including virtual memory system,
MTT Extensions) enforces the access-control for confidential memory against
other supervisor domains. The region sizes at which the memory tracking enforces
isolation may be multiples of the architectural page sizes supported by the hart
MMU. The IOMMU is expected to support a similar memory tracking lookup
to enable a device/function trusted by the TVM to directly access
TVM confidential memory regions. For the CoVE reference architecture this TCB
consists of the HW (e.g. MMU, IOMMU, Memory Controller) and the SW/FW elements -
TSM-driver and the TSM. The TSM-driver is responsible for enforcing isolation of
confidential memory regions (consisting of multiple pages via MTT) and the TSM
is responsible for enforcing isolation of confidential memory pages among TVMs
(via G-stage translation) - pages assigned to the TVM may be exclusively
accessible to the condidential supervisor domain or may be shared with the
hosting supervisor domain (e.g. to allow for paravirtualized IO access).

[NOTE]
====
The TSM may manage additional attributes on TVM-assigned pages such as:
TVM-owner, Page-sub-type, TLB versioning information, Locking semaphore and
additional metadata etc. This extended memory tracking information managed by
the TSM software is referred to as the Extended Memory Tracking Table (EMTT).
====

==== Handling Implicit & Explicit Memory Accesses
For TVM accesses for instruction fetch and page walks, isolated/confidential
memory is required to enforce the following security properties:

* TEE Instruction fetch - security property: TVM/TSM must not fetch code
from untrusted/shared memory - enforced by the hart
* TEE Paging structure walk - security property: TVM and TSM must not locate
page tables in untrusted shared memory.
* TEE data fetch - security property: The TVM via the TSM may be allowed to
relax data accesses to non-confidential memory (via MTT) to allow for IO
accesses.

==== Cached translations/TLB management
During confidential memory conversion or reclamation, the HW TCB
and SW TCB (TSM) must enforce via memory-management fences
that stale data is not accessible to the TVM (or the hosting OS/VMM).
During confidential memory assignment to a TVM (or during conversion
of confidential memory to shared), the TCB must enforce that stale
translations may not be held to memory yielded by a TVM (and used
by the host for another TVM or VM or the host).
These properties are implemented by the TSM in conjunction with
the HW (e.g. MTT cache invalidations) via the proposed COVH interface.

=== TSM initialization

The CoVE architecture requires a hardware Root-of-trust for supporting
TCB measurement, reporting and storage <<R8>>. The Root-of-trust for
Measurement (RTM) is defined as the TCB component that performs a
measurement of an entity and cryptographically signs it as attestation
evidence subsequently reported to a relying party. The
Root-of-trust for Reporting (RTR) is typically a HW RoT that reliably
provides authenticity and non-repudiation services for the purposes of
attesting to the origin, integrity and security version of platform TCB
components. Each TCB layer should have associated security version numbers
(SVN) to allow for TCB recovery in the event of security vulnerabilities
discovered in a prior version of the TCB layer.

During platform initialization, HW/FW elements form the RTM that measure the
TSM-driver. The TSM-driver acts as the RTM for the TSM loaded on the
platform. The TSM-driver initializes the TSM-memory-region for the TSM -
this TSM-memory-region must be in confidential memory. The TSM binary may be
provided by the OS/VMM which may independently authenticate the binary
before loading the binary into the TSM-memory-region via the TSM-driver.
Alternatively, the platform firmware may pre-load the RoT-authenticated TSM
binary via the TSM-driver.

In both cases, the TSM binary loaded must be measured and may be
authenticated (per cryptographic signature mechanisms) by the TSM-driver
during the loading process, so that the TSM used is reflected in the
attestation rooted in a HW RoT. The authentication process provides
additional control to restrict TSM binaries that can be loaded on the
platform based on policies such as version, vendor etc. In addition to the
measurements, a security version number (SVN) of the TSM should be recorded
by the TSM-driver into the firmware measurement registers accessible only
to the TSM-driver and higher privilege components. The measurements and
versions of the HW RoT, the TSM-driver and the TSM will subsequently be
provided as evidence of a specific TSM being loaded on a specific platform.

During initialization, the TSM-driver will initialize a TSM-data region
within the TSM-memory region. The TSM-data region may hold per-hart TSM
state, memory assignment tracking structures and additional global data for
TSM management. The TSM-data region is confidential memory that is apriori
access-control-restricted by the TSM-driver to allow only the TSM to access
this memory. The per-hart TSM state is used to start TSM execution from a
known-good state for security routines invoked by the OS/VMM. The per-hart
TSM state should be stored in confidential memory in TSM Hart Control Structures
(THCS - See <<appendix_a>>) which is initialized as part of the TSM memory
initialization. The THCS structure definition is part of the COVH ABI and may
be extended by an implementation, with the minimum state shown in the
structure. Isolating and establishing the execution state of the TSM is the
responsibility of the TSM-driver. Saving and restoring the execution
state of the TSM (for interrupted routines) is performed by the TSM. The
operating modes of the TSM are described in <<TSM operation and properties>>.
Saving and restoring the TVM execution state in the TVM virtual-harts (called
the VHCS) is the responsibility of the TSM and is held in confidential memory
assigned to the TVM by the VMM.

=== TSM operation and properties

The TSM implements COVH APIs that are invoked by the OS/VMM or by
the TVMs, e.g. by the VMM to grant a TVM a confidential memory page and
setup second-stage mapping, activate a TVM virtual hart on a physical hart
etc. The TSM security routines are invoked by the OS/VMM via an ECALL with
the service call specified via registers. These service calls trap to the
TSM-driver. The TSM-driver switches hart state to the TSM context by
loading the hart's TSM execution state from the THCS.tssa and then returns
via an MRET to the TSM. The TSM executes the security routine requested
(where the TSM enforces the security properties) and may either return to
the OS/VMM via an ECALL to the TSM-driver (TEERET with reason), or may use
an SRET to return/enter into a TVM. On a subsequent TVM synchronous or
asynchronous trap (due to ECALLs or any exception/interrupt) from a TVM,
the TSM handles the cases delegated to it by the TSM-driver (via mideleg and
medeleg).
The TSM saves the TVM state and invokes the TSM-driver via an ECALL (TEERET
with reason) to initiate the return of execution control to the OS/VMM if
required. The TSM-driver restores the context for the OS/VMM via the
per-hart control sub-structure THCS.hssa (See <<appendix_a>>).This canonical
flow is shown in figure 3.

Beyond the basic operation described above, the following different
operational models of the TSM may be supported by an implementation:

* *Uninterruptible* *TSM* - In this model, the TSM security routines are
executed in an uninterruptible manner for S-mode interrupts (M-mode
interrupts are not inhibited). This implies that the TSM execution always
starts from a fixed initial state of the TSM harts and completes the
execution with either a TEERET to return control to the OS/VMM or via an
SRET to enter into a TVM (where the execution may be interruptible again).

* *Interruptible TSM with no re-entrancy* - In this model, after the
initial entry to the TSM with S-mode interrupts disabled, the TSM enables
interrupts during execution of the TSM security routines. The TSM may
install its interrupt handlers at this entry (or may be installed via the
TEECALL flow as shown below). On an S-mode interrupt, the TSM hart context
is saved by the TSM and keeps the interrupt pending. The TSM may then
TEERET to the host OS/VMM with explicit information about the interruption
provided via the pending interrupt to the OS/VMM. The TSM-driver supports a
TEERESUME ECALL which enables the TSM to enforce that the resumption of the
interrupted TSM security routine is initiated by the OS/VMM on the same
hart. The TSM hart context restore is enforced by the TSM to allow for the
resumed TSM security routine operation to complete. Intermediate
state of the operation must be saved and restored by the TSM for such
flows.

**__This specification describes the operation of the TSM in this
mode of operation.__**

* *Interruptible and re-entrant TSM* - In this model, similar to the
previous case, the TSM security routines are executed in an interruptible
manner, but are also allowed to be re-entrant. This requires support for
trusted thread contexts managed by the TSM. A TSM security routine invoked
by the OS/VMM is executed in the context of a specific TSM thread context
(a stack structure may also be used). On an interruption of that routine
using a TSM thread context, the TSM saves the TSM execution context for the
TSM thread and returns control to the OS/VMM via a TEERET. The OS/VMM can
handle the interrupt and may resume that TSM thread or may invoke another
TSM security routine on a different (non-busy) thread context (and on a
different hart). This model of TSM operation requires additional
concurrency controls on internal data structures and per-TVM global data
structures (such as the G-stage page table structures).

[caption="Figure {counter:image}: ", reftext="Figure {image}"]
[title= "TSM operation - Interruptible and non-reentrant TSM model shown."]
image::img_3.png[]

A TSM entry triggered by an ECALL (with CoVE extension type) by the OS/VMM
leads to the following context-switch to the TSM (performed by the
TSM-driver):

The initial state of the TSM will be to start with a fixed reset value for
the registers that are restored on resumed security operations.

*ECALL (* *TEECALL* */ TEERESUME* *)* *pseudocode - implemented by the
TSM-driver*

* If trap is a synchronous trap due to TEECALL/ TEERESUME then activate
confidential supervisor domain for the hart via M-mode `mttp` CSR (See
Supervisor Domains specification <<R20>> for CSR definition)
* Locate the per-hart THCS (located within TSM-driver memory data region)
* Save operating VMM csr context into the THCS.hssa (Hart Supervisor State
Area) fields : sstatus, stvec, scounteren, sscratch, satp (and other x
state other than a0, a1 - see <<appendix_a>>). Note that
any v/f register state must be saved by the caller.
* Save THCS.hssa.pc as mepc+4 to ensure that a subsequent resumption
happens from the pc past the TEECALL
* Establish the TSM operating context from the THCS.tssa (TSM Supervisor
State Area) fields (See <<appendix_a>>)
* Set scause to indicate TEECALL
* Disable interrupts via sie=0.
  ** For a preemptable TSM, interrupts do not stay disabled - the TSM may
enable interrupts and so S/M-mode interrupts may occur while executing in
the TSM. S-mode interrupts will cause the TSM to save state and TEERET.
* MRET to resume execution in TSM at THCS.tssa.stvec

*ECALL (synchronous explicit TEERET) OR Asynchronous M-mode trap pseudocode
- implemented by TSM-driver*

* Locate the per-hart THCS (located within TSM-driver memory data region)
* If Asynchronous M-mode trap:
  ** Handle M-mode trap
  ** If required, pend an S-mode interrupt to the TSM and SRET
* _Implementation Note -_ _The TSM-driver does not need to keep state of
the TSM being interrupted as, on an interrupt the TSM can enforce:_
  ** _If it was preemptable but not-reentrant that the next invocation on
that hart is a TEERESUME with identical parameters as the interrupted
security routine._
  ** _If the TSM was preemptable and re-entrant then the TSM would accept
both TEERESUME and TEECALL as subsequent invocations (as long as TSM
threads are available)._
* Restore the OS/VMM state saved on transition to the TSM: sstatus, stvec,
scounteren, sscratch, satp and x registers (other than a0, a1). Note that
any v/f register state must be restored by the caller.
* TSM-driver passes TSM/TVM-specified register contents to the OS/VMM to
return status from TEERET (TSM sets a0, a1 registers always - other
registers may be selected by the TVM)
* Enable hosting supervisor domain on hart (via Superisor Domains <<R20>>
M-mode CSR `mttp` to disable non-TCB accesses to confidential memory.)
* MRET to resume execution in OS/VMM at mepc set to THCS.hssa.pc
(THCS.hssa.pc adjusted to refer to opcode after the ECALL that triggered
the TEECALL / TEERESUME)

The TSM is stateless across TEECALL invocations, however a security routine
invoked in the TSM via a TEECALL may be interrupted and must be resumed via
a TEERESUME i.e. _the TSM is preemptable but non-reentrant_. These
properties are enforced by the TSM-driver, and other models described above
may be implemented. The TSM does not perform any dynamic resource
management, scheduling, or interrupt handling of its own. The TSM is not
expected
to issue IPIs itself; the TSM must track if appropriate IPIs are issued by the
host OS/VMM to track that the required security checks are performed on each
physical hart (or virtual hart context) as required by specific COVH/G flows.

When the TSM is entered via the TSM-driver (as part of the ECALL [TEECALL]
- MRET), the TSM starts with sstatus.sie set to 0 i.e. interrupts disabled.
The sstatus.sie does not affect HS interrupts from being seen when mode =
U/VS/VU. The OS/VMM sip and sie will be saved by the TSM in the HSSA and
will retain the state as it existed when the host OS/VMM invoked the TSM.
The TSM may establish the execution context and re-enable interrupts
(sstatus.sie set to 1).

If an M-mode interrupt occurs while the hart is operating in the TSM or any
TVM, the control always goes to the TSM-driver handler, which can handle
it, or if the event must be reported to the untrusted OS/VMM, they are
pended as S-mode interrupts to the TSM which must save its execution
context and return control to the OS/VMM via a TEERET.

If an S-mode interrupt occurs while the hart is operating in the TSM
(HS-mode), it should preempt out and return to the OS/VMM using TEERET.
The TSM may take certain actions on S-mode interrupts - for example, saving
status of a host security routine, and/or change the status of TVMs. The
TSM is however not expected to retire the S-mode interrupt but keep the
event pending so they are taken when control returns to the OS/VMM via the
TEERET.

If a S-mode interrupt occurs in U, VU or VS - external, timer, or software
- then that causes the trap handler in TSM to be invoked. In response to
trap delivery, the TSM saves the TVM virtual-hart state and returns to the
OS/VMM via a TEERET ECALL. As part of return to the OS/VMM, the sstatus of
OS/VMM is restored and when the OS starts executing the pending interrupt -
external, timer, or software - may or may not be taken depending on the OS
sstatus.sie. Under these circumstances the saving of the TVM state is the
TSM responsibility.

When TVM is executing, hideleg will only delegate VS-mode external
interrupt, VS-mode SW interrupt, and VS-mode timer interrupts to the TVM.
S-mode SW/Timer/External interrupts are delegated to the TSM (with the
behavior described above). _All other interrupts_ , M-mode
SW/Timer/External, bus error, high temp, RAS etc. are not delegated and
delivered to M-mode/TSM-driver. Under these circumstances the saving of the
state is the TSM-driver responsibility. Also since scrubbing the TVM state
is the TSM responsibility, the TSM-driver may pend an S-mode interrupt to
the TSM to allow cleanup on such events. See <<appendix_b>> for a table of
interrupt causes and handling requirements.

The TSM may not need to program stimecmp on its own, though it may verify
that time is not going back for a TVM. If the TSM needs to start a timer,
it should context switch the stimecmp CSR and replace it with its timeout
value if it's later than the timer it wants to start. The TSM may still
want to be aware of the value programmed into stimecmp to guard against
step attacks on TVMs.

Any NMIs experienced during TSM/TVM execution are always handled by the
TSM-driver and must cause the TEEs to be destroyed (preventing any loss of
confidential info via clearing of machine state). The TSM and therefore all
TVMs are prevented from execution after that point.

=== TSM and TVM Isolation

TSM (and all TVMs) memory is granted by the host OS/VMM but is isolated
(via access-control and/or confidentiality-protection) by the HW and TCB
elements. The TSM, TVM and HW isolation methods used must be evident in the
attestation evidence provided for the TVM since it identifies the hardware
and the TSM-driver.

There are two facets of TVM and TSM memory isolation that are
implementation-specific:

*a)* *Isolation from host software access* -  For the deployment model (a),
the CPU must enforce hardware-based access-control of TSM memory via
the G-stage page tables to prevent the guest VMM from accessing TSM
memory. For the deployment model (b). The CPU must also similarly enforce
access-control of TSM memory to prevent access from host supervisor
domain components (VMM and host OS that operate in V=0, HS-mode) software.
Since in this deployment model (b), other supervisor domains have access to 1st
and G-stage paging hardware, the root security manager (TSM-driver) must use MTT
to isolate supervisor domain memory. In this deployment model,
TEE and TVM address spaces are identified by supervisor domain identifiers
(Smsdid) to maintain the isolation during access and in internal
address translation caches, e.g. Hart TLB lookup may be extended with the
SDID in addition to the ASID, VMID for workloads in the Confidential supervisor
domain. TVM memory isolation must support sparse memory management
models and architectural page-sizes of 4KB, 64K, 2MB, 1GB (and optionally
512GB). The hardware may implement the MTT as specified in the Smmtt
privileged ISA extension, or other approaches may be used such as a flat
table. The memory tracking table may be enforced at the memory controller,
or in a page table walker.

*b)* *Isolation against physical/out-of-band access* - The platform TCB may
provide confidentiality, integrity and replay-protection. This may be
achieved via a Memory Encryption Engine (MEE) to prevent TEE state being
exposed in volatile memory during execution. The use of an MEE and the
number of encryption domains supported is implementation-specific. For
example, The hardware may use the Supervisor Domain Identifier during execution
(and memory access) to cryptographically isolate memory associated with a
TEE which may be encrypted and additionally cryptographically
integrity-protected using a MAC on the memory contents. The MAC may be
maintained at various granularity - e.g. cache block size or in multiples
of cache blocks.

*TVM isolation* is the responsibility of the TSM via the G-stage
address translation table (hgatp). The TSM must track memory assignment of
TVMs (by the untrusted VMM/OS) to ensure memory assignment is
non-overlapping, along with additional security requirements. The security
requirements/invariants for enforcement of the memory
access-control for memory assigned to the TVMs is described in <<TVM Memory
management>>.

=== TVM Execution

As described above, TVMs can access both classes of memory - isolated memory
- which has confidentiality and access-control properties for memory exclusive
to the TVM, and non-confidential memory which is memory accessible to the host
OS/VMM and is used for untrusted operations (e.g. virtio, gRPC communication
with the host). If the confidential memory is access-controlled only, the TSM
and TSM-driver are the authority over the access-control enforcement. If the
confidential memory is using memory encryption (instead or in addition), the
encryption keys used for confidential memory must be different from
non-confidential memory.

All TVM memory is mapped in the second-stage page tables controlled by the
TSM explicitly - the allocation of memory for the G-stage paging
structures pages used for the G-stage mapping is also performed by the
OS/VMM but the security properties of the G-stage mapping are enforced
by the TSM. By default any memory mapped to a TVM is confidential. A TVM
may then explicitly request that confidential memory be converted to
non-confidential memory regions using services provided by the TSM. More
information about TVM Execution and the lifecycle of a TVM is described in
the <<TVM Lifecycle>> section of this document.

=== Debug and Performance Monitoring

The following additional considerations are noted for debug and performance
monitoring:

*Debug mode considerations*

In order to support probe-mode debugging of the TSM, the RoT must support
an authorized debug of the platform. The authentication mechanism used for
debug authorization is implementation-specific, but must support the
security properties described in the Section 3.12 of the RISC-V Debug
Support specification version 1.0.0-STABLE <<R6>>. The RoT may support
multiple levels of debug authorization depending on access granted. For
probe-based debugging of the hardware, the RoT performing debug
authentication must ensure that separate attestation keys are used for TCB
reporting when probe-debug is authorized vs when the platform is not under
probe-debug mode. The probe-mode debug authorization process must invalidate
sealed keys to disallow sealed data access when in probe-debug modes. Note that
the external debug opt-in control for the hosting supervisor domain must be
independent from the confidential supervisor domain. Similarly, external debug
controls should be independently managed by the RoT to allow for root security
manager (TSM-driver) debug.

When a TVM is under self-hosted debugging - on a transition to TVM
execution, the TSM-driver must set up the trigger CSRs for the TVM. For TVM
debugging, the TSM-driver may inhibit M and S/HS modes in the triggers. On
transitions back to the OS/VMM, the TSM-driver will save the trigger CSRs
and associated debug states, thus not leaking any information to non-TEE
workloads. TVM self-hosted debug may be enabled from TVM creation time or
may be explicitly opted-into during execution of the TVM. The TSM may
invoke the TSM-driver to set up a TVM-specific trigger CSR state (per the
configuration of the TVM).

*Performance Monitoring considerations*

By default the TSM and all TVMs run with performance monitoring suppressed.
If a TVM runs in this default mode (opted out of performance monitoring),
on a transition to the TVM, the TSM-driver enforces this via inhibiting the
counters (using mcountinhibit).

The TVM may opt-in to use performance monitoring either at initialization or
post-initialization of the TVM.

If the TVM has opted-in to performance monitoring, the TSM may invoke the
SBI PMU extension (via TSM-driver) or use M-mode counter delegation
(Smcdeleg) and Supervisor counter configuration (Ssccfg) extensions to
establish TVM-specific controls and configuration that allows performance
monitoring in a TVM. However, the TVM must use SBI PMU extension unless
TSM supports full
trap & emulate support for the hpmcounter related ISA extensions. The TSM will
assign a virtual counter to the TVM for the events requested to be monitored by
the TVM in either approach. The TSM needs to manage a mapping between the
virtual and physical counters as well. It must not delegate the LCOFI interrupt
(via hideleg[13]=1) for the TVM and use the interrupt filtering mechanism
defined in the Advanced Interrupt Architecture (AIA) to inject the LCOFI
interrupt when the physical counter corresponding to the virtual counter
overflows. The physical counters naturally inhibit counting in S/HS and M. The
TSM must save and  clear counter/event selector values as control transitions to
the VMM or a different TVM that is using hpm. On a transition back to the host
OS/VMM, the TSM must restore the saved hardware performance monitoring event
triggers and counter enables. If the TSM uses the SBI PMU extension instead of
Supervisor counter delegation, the TSM-driver needs to perform the save/restore
on behalf of the TSM.
