Documentation/arch/powerpc/ultravisor.rst
Source file repositories/reference/linux-study-clean/Documentation/arch/powerpc/ultravisor.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/arch/powerpc/ultravisor.rst- Extension
.rst- Size
- 34641 bytes
- Lines
- 1118
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0
.. _ultravisor:
============================
Protected Execution Facility
============================
.. contents::
:depth: 3
Introduction
############
Protected Execution Facility (PEF) is an architectural change for
POWER 9 that enables Secure Virtual Machines (SVMs). DD2.3 chips
(PVR=0x004e1203) or greater will be PEF-capable. A new ISA release
will include the PEF RFC02487 changes.
When enabled, PEF adds a new higher privileged mode, called Ultravisor
mode, to POWER architecture. Along with the new mode there is new
firmware called the Protected Execution Ultravisor (or Ultravisor
for short). Ultravisor mode is the highest privileged mode in POWER
architecture.
+------------------+
| Privilege States |
+==================+
| Problem |
+------------------+
| Supervisor |
+------------------+
| Hypervisor |
+------------------+
| Ultravisor |
+------------------+
PEF protects SVMs from the hypervisor, privileged users, and other
VMs in the system. SVMs are protected while at rest and can only be
executed by an authorized machine. All virtual machines utilize
hypervisor services. The Ultravisor filters calls between the SVMs
and the hypervisor to assure that information does not accidentally
leak. All hypercalls except H_RANDOM are reflected to the hypervisor.
H_RANDOM is not reflected to prevent the hypervisor from influencing
random values in the SVM.
To support this there is a refactoring of the ownership of resources
in the CPU. Some of the resources which were previously hypervisor
privileged are now ultravisor privileged.
Hardware
========
The hardware changes include the following:
* There is a new bit in the MSR that determines whether the current
process is running in secure mode, MSR(S) bit 41. MSR(S)=1, process
is in secure mode, MSR(s)=0 process is in normal mode.
* The MSR(S) bit can only be set by the Ultravisor.
* HRFID cannot be used to set the MSR(S) bit. If the hypervisor needs
to return to a SVM it must use an ultracall. It can determine if
the VM it is returning to is secure.
* There is a new Ultravisor privileged register, SMFCTRL, which has an
enable/disable bit SMFCTRL(E).
* The privilege of a process is now determined by three MSR bits,
MSR(S, HV, PR). In each of the tables below the modes are listed
from least privilege to highest privilege. The higher privilege
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.