

==Rationale==

===Efficiency===

For a high end device, the best energy efficiency and highest performance
are probably provided with multiple instances of a processor.  However,
for a low end, inexpensive device, multiple environments should share
the same processor to reduce the area requriements.

One thing preventing the utilization of this scheme is the software complexity.
Currently, if two environments are to be merged into a single processor, the 
two environments need to be linked and debugged together.  This would make 
(for example) a combined OpenDSP and Modem processor very difficult to achieve.

Using the concept of Virtualization, it can be possible to have multiple
environments share the same physical processor while maintaining the
programming model of separate processor images.  The Hypervisor can provide
separation between the two virtual machines, which can communicate in the same
way on a shared core as on multiple cores (for example, using the Shared Memory
Driver).

===Dynamic Power Control===

When sharing the same DSP hardware with multiple software environments happens,
none of the environments can be authoritative for power collapse.  Instead,
power collapse should be handled by the Hypervisor based on performance and
latency requirements of the guests running on the processor.  Additionally,
abstracting power collapse functionality in this way allows for compatibility
during changes in the power collapse hardware provided (for example, if a local
head switch is available or not).

This flexibility to share or not share using the same software image will
become more important as the energy consumed by leakage continues to become a
bigger problem.  In a scenario where utilization across all processors is low,
such as a voice call, the virtual machines can be dynamically migrated to a
reduced number of shared cores, or a single core, and the other cores can
be power collapsed to eliminate leakage.  When the processing demand increases,
the other cores can be turned back on and virtual machines can be migrated 
back to redistribute the load.

===Compatibility===

While user mode is continually backward compatible on the Hexagon processor,
the most privileged mode (monitor mode) is allowed to change with each version
of the processor.  While this gives the Hexagon team a large amount of
flexibility to make improvements, it requires that the most privileged software
(currently, the RTOS) to make substantial changes with each core release.
This causes substantial effort on the part of the RTOS team, and since 
the RTOS is included in the build, the final image loaded on the DSP can not
be compatible with future versions of the processor.

By having the RTOS use the Guest Architecture, which maintains compatibility
across processor versions, the entire image can be compatible across future
versions of the core; conceivably an MSM8660 Audio image could run on MSM8960,
for example, even though the Hexagon processors in those devices are
dramatically different.

===Correctness===

Various software sequences, such as cleaning the caches or saving debug state
before power collapse, vary between core versions and are difficult to ensure
correctness for.  As the Hexagon cores continue to evolve, these difficult
sequences will likely also continue to change.  Additionally, hardware issues
may further complicate some of these sequences.

Some hardware issues are found after silicon has been developed.  Managing
these "chicken bits" and clock gating controls can be difficult and error
prone.

The Hypervisor can abstract these interfaces and make procedures like power
collapse and warm boot more transparent to the guest operating systems and
compatible between versions.  Furthermore, the Hypervisor can be tested along
with the RTL during core verification to ensure that both the hardware and 
the Hypervisor are working together to correctly enter and return from power
collapse, voltage minimization, or other future tricky state transitions.


==Overhead Concerns==

One of the concerns with introducing a Hypervisor is whether it will introduce
substantial overhead, especially for performance-sensitive environments.

We propose a novel RTOS environment built on top of the Hypervisor.  Unlike a
traditional Hypervisor model, where both the RTOS and the Hypervisor have a
scheduler, we propose to use only the Hypervisor scheduler for an efficient
RTOS environment.  In effect, each RTOS task gets a "Virtual CPU" in the
Hypervisor. 

We add a very small number of configurable calls into this monitor to provide
efficient synchronization between tasks, whether in Guest or User mode.  Rather
than adding a layer, we are dividing the RTOS services up into ones provided
by the Guest operating system, and ones provided directly by the Hypervisor.
This reduces the scenarios under which there is performance overhead for using
a Hypervisor over running an RTOS on the "bare metal".

In current Hexagon implementations, there will still be a small additional
overhead for certain things such as traps from user to guest mode.  We expect
that these overheads can be kept very small, and that we can add additional
hardware support in future Hexagon processors to reduce places where there
is a performance overhead to using a Hypervisor.



==Security==

===Hypervisor Protection===

The Hypervisor is protected from user and guest environments.  Hypervisor register
state is protected by the hardware, and hypervisor memory is excluded from 
being accessable by any guest.

===Guest Protection===

The Hypervisor can enforce protection between guests.  Guests can be configured
to have completely independent memory maps, or memory maps that are shared only
in specific areas (such as space for shared memory communication).

===Debug Protection===

The Hypervisor will provide a mechanism to debug multiple Guest environments
securely.  The Hypervisor can provide a mechanism for communication to each
Guest Virtual CPU, which the Guest can choose to communicate or not.  This 
will allow secure environments such as sensitive modem code, or DRM-sensitive
Multimedia environments.

===System MMU Integration===

Devices typically are designed to utilize a large, contiguous block of memory.
Allocating such a block of memory for a device is very difficult for most
operating system environments.  Additionally, devices accessing memory must 
be protected such that device defects or incorrect programming does not 
cause memory to be accessed by a device incorrectly.

System MMUs were developed to address these concerns.  The High Level Operating
System (HLOS) can programm a System MMU to present a contiguous range of memory
to a device, which gets translated into some number of pages of physical memory.
A device can potentially even sit in an application's virtual address space.

There is a desire to have DSP environments exist behind a System MMU.  However,
the current System MMU hardware is unlikely to provide an effective solution
for the Hexagon processor:

* A System MMU adds substantial area to the overall deliverable

* System MMUs add latency to every memory transaction, resulting in performance degradation and increased energy consumption

* System MMUs are currently designed to operate at frequencies that are not sufficient for all Hexagon environments (such as Dime modem)

* System MMUs are currently blocking when a page miss happens, stalling other accesses from other threads

* System MMUs turn Hexagon caches into Virtual caches, presenting a wide variety of programming problems, such as virtual aliasing, and hardware problems, such as difficulty in debugging and an impossibility for bus-based cache coherency.

* Neither the System MMUs nor the Hexagon processor is designed to transmit additional information about what environment corresponds to each transaction, and a shared DSP would need more than one context to be supported.

Fundimentially, a System MMU is duplicating functionality already available in
the Hexagon processor: namely, the ability to translate addresses.  Instead, we
propose to offer a Soft System MMU (SSMMU).  This will have the same
programming model as a SMMU, but be implemented in the Hypervisor.  

The Hypervisor will walk the page tables defined in the SMMU interface.  This
can allow for an environment where an entire Guest OS (such as Audio) lives in
an address space defined by an SMMU memory map.

The SSMMU interface can likely be implemented to support most SMMU
functionality even in existing MSM devices (such as 8660 or 8960).  To have
complete SMMU functionality, certain simple interfaces need to be added.

Our plan is to develop SSMMU functionality and demonstrate it on existing 
platforms and to develop full SMMU compatibility targetting a future device.




