From: Steven Price <steven.price@arm.com>
To: kvm@vger.kernel.org, kvmarm@lists.linux.dev
Cc: Steven Price <steven.price@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
James Morse <james.morse@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Joey Gouly <joey.gouly@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Christoffer Dall <christoffer.dall@arm.com>,
Fuad Tabba <tabba@google.com>,
linux-coco@lists.linux.dev,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
Gavin Shan <gshan@redhat.com>,
Shanker Donthineni <sdonthineni@nvidia.com>,
Alper Gun <alpergun@google.com>,
"Aneesh Kumar K . V" <aneesh.kumar@kernel.org>
Subject: [PATCH v6 11/11] arm64: Document Arm Confidential Compute
Date: Fri, 4 Oct 2024 15:43:06 +0100 [thread overview]
Message-ID: <20241004144307.66199-12-steven.price@arm.com> (raw)
In-Reply-To: <20241004144307.66199-1-steven.price@arm.com>
Add some documentation on Arm CCA and the requirements for running Linux
as a Realm guest. Also update booting.rst to describe the requirement
for RIPAS RAM.
Signed-off-by: Steven Price <steven.price@arm.com>
---
Documentation/arch/arm64/arm-cca.rst | 67 ++++++++++++++++++++++++++++
Documentation/arch/arm64/booting.rst | 3 ++
Documentation/arch/arm64/index.rst | 1 +
3 files changed, 71 insertions(+)
create mode 100644 Documentation/arch/arm64/arm-cca.rst
diff --git a/Documentation/arch/arm64/arm-cca.rst b/Documentation/arch/arm64/arm-cca.rst
new file mode 100644
index 000000000000..ab7f90e64c2f
--- /dev/null
+++ b/Documentation/arch/arm64/arm-cca.rst
@@ -0,0 +1,67 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Arm Confidential Compute Architecture
+=====================================
+
+Arm systems that support the Realm Management Extension (RME) contain
+hardware to allow a VM guest to be run in a way which protects the code
+and data of the guest from the hypervisor. It extends the older "two
+world" model (Normal and Secure World) into four worlds: Normal, Secure,
+Root and Realm. Linux can then also be run as a guest to a monitor
+running in the Realm world.
+
+The monitor running in the Realm world is known as the Realm Management
+Monitor (RMM) and implements the Realm Management Monitor
+specification[1]. The monitor acts a bit like a hypervisor (e.g. it runs
+in EL2 and manages the stage 2 page tables etc of the guests running in
+Realm world), however much of the control is handled by a hypervisor
+running in the Normal World. The Normal World hypervisor uses the Realm
+Management Interface (RMI) defined by the RMM specification to request
+the RMM to perform operations (e.g. mapping memory or executing a vCPU).
+
+The RMM defines an environment for guests where the address space (IPA)
+is split into two. The lower half is protected - any memory that is
+mapped in this half cannot be seen by the Normal World and the RMM
+restricts what operations the Normal World can perform on this memory
+(e.g. the Normal World cannot replace pages in this region without the
+guest's cooperation). The upper half is shared, the Normal World is free
+to make changes to the pages in this region, and is able to emulate MMIO
+devices in this region too.
+
+A guest running in a Realm may also communicate with the RMM to request
+changes in its environment or to perform attestation about its
+environment. In particular it may request that areas of the protected
+address space are transitioned between 'RAM' and 'EMPTY' (in either
+direction). This allows a Realm guest to give up memory to be returned
+to the Normal World, or to request new memory from the Normal World.
+Without an explicit request from the Realm guest the RMM will otherwise
+prevent the Normal World from making these changes.
+
+Linux as a Realm Guest
+----------------------
+
+To run Linux as a guest within a Realm, the following must be provided
+either by the VMM or by a `boot loader` run in the Realm before Linux:
+
+ * All protected RAM described to Linux (by DT or ACPI) must be marked
+ RIPAS RAM before handing over the Linux.
+
+ * MMIO devices must be either unprotected (e.g. emulated by the Normal
+ World) or marked RIPAS DEV.
+
+ * MMIO devices emulated by the Normal World and used very early in boot
+ (specifically earlycon) must be specified in the upper half of IPA.
+ For earlycon this can be done by specifying the address on the
+ command line, e.g.: ``earlycon=uart,mmio,0x101000000``
+
+ * Linux will use bounce buffers for communicating with unprotected
+ devices. It will transition some protected memory to RIPAS EMPTY and
+ expect to be able to access unprotected pages at the same IPA address
+ but with the highest valid IPA bit set. The expectation is that the
+ VMM will remove the physical pages from the protected mapping and
+ provide those pages as unprotected pages.
+
+References
+----------
+[1] https://developer.arm.com/documentation/den0137/
diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst
index b57776a68f15..30164fb24a24 100644
--- a/Documentation/arch/arm64/booting.rst
+++ b/Documentation/arch/arm64/booting.rst
@@ -41,6 +41,9 @@ to automatically locate and size all RAM, or it may use knowledge of
the RAM in the machine, or any other method the boot loader designer
sees fit.)
+For Arm Confidential Compute Realms this includes ensuring that all
+protected RAM has a Realm IPA state (RIPAS) of "RAM".
+
2. Setup the device tree
-------------------------
diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst
index 78544de0a8a9..12c243c3af20 100644
--- a/Documentation/arch/arm64/index.rst
+++ b/Documentation/arch/arm64/index.rst
@@ -10,6 +10,7 @@ ARM64 Architecture
acpi_object_usage
amu
arm-acpi
+ arm-cca
asymmetric-32bit
booting
cpu-feature-registers
--
2.34.1
next prev parent reply other threads:[~2024-10-04 14:44 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-04 14:42 [PATCH v6 00/11] arm64: Support for running as a guest in Arm CCA Steven Price
2024-10-04 14:42 ` [PATCH v6 01/11] arm64: rsi: Add RSI definitions Steven Price
2024-10-07 23:08 ` Gavin Shan
2024-10-11 14:14 ` Steven Price
2024-10-04 14:42 ` [PATCH v6 02/11] arm64: Detect if in a realm and set RIPAS RAM Steven Price
2024-10-04 15:05 ` Steven Price
2024-10-11 13:12 ` Catalin Marinas
2024-10-07 23:31 ` Gavin Shan
2024-10-11 14:14 ` Steven Price
2024-10-04 14:42 ` [PATCH v6 03/11] arm64: realm: Query IPA size from the RMM Steven Price
2024-10-07 23:33 ` Gavin Shan
2024-10-15 3:55 ` Gavin Shan
2024-10-15 9:08 ` Steven Price
2024-10-04 14:42 ` [PATCH v6 04/11] arm64: rsi: Add support for checking whether an MMIO is protected Steven Price
2024-10-08 0:24 ` Gavin Shan
2024-10-11 14:14 ` Steven Price
2024-10-04 14:43 ` [PATCH v6 05/11] arm64: rsi: Map unprotected MMIO as decrypted Steven Price
2024-10-08 0:31 ` Gavin Shan
2024-10-11 13:19 ` Catalin Marinas
2024-10-12 5:22 ` Gavin Shan
2024-10-11 13:20 ` Catalin Marinas
2024-10-04 14:43 ` [PATCH v6 06/11] efi: arm64: Map Device with Prot Shared Steven Price
2024-10-08 0:31 ` Gavin Shan
2024-10-11 13:23 ` Catalin Marinas
2024-10-04 14:43 ` [PATCH v6 07/11] arm64: Enforce bounce buffers for realm DMA Steven Price
2024-10-08 2:51 ` Gavin Shan
2024-10-04 14:43 ` [PATCH v6 08/11] arm64: mm: Avoid TLBI when marking pages as valid Steven Price
2024-10-08 2:52 ` Gavin Shan
2024-10-15 9:50 ` Suzuki K Poulose
2024-10-04 14:43 ` [PATCH v6 09/11] arm64: Enable memory encrypt for Realms Steven Price
2024-10-08 2:56 ` Gavin Shan
2024-10-04 14:43 ` [PATCH v6 10/11] virt: arm-cca-guest: TSM_REPORT support for realms Steven Price
2024-10-05 15:42 ` kernel test robot
2024-10-08 4:12 ` Gavin Shan
2024-10-11 14:14 ` Steven Price
2024-10-11 16:22 ` Suzuki K Poulose
2024-10-12 6:06 ` Gavin Shan
2024-10-14 8:56 ` Suzuki K Poulose
2024-10-14 14:41 ` Steven Price
2024-10-14 14:46 ` Suzuki K Poulose
2024-10-15 0:01 ` Gavin Shan
2024-10-04 14:43 ` Steven Price [this message]
2024-10-08 4:17 ` [PATCH v6 11/11] arm64: Document Arm Confidential Compute Gavin Shan
2024-10-08 11:05 ` Jean-Philippe Brucker
2024-10-11 14:14 ` Steven Price
2024-10-15 9:55 ` Suzuki K Poulose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241004144307.66199-12-steven.price@arm.com \
--to=steven.price@arm.com \
--cc=alexandru.elisei@arm.com \
--cc=alpergun@google.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@arm.com \
--cc=gankulkarni@os.amperecomputing.com \
--cc=gshan@redhat.com \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=sdonthineni@nvidia.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox