From nobody Mon Apr 6 18:24:00 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A6E7B3EC2F2; Wed, 18 Mar 2026 15:55:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773849312; cv=none; b=MmF/abf5HS8ZIsn7fTytc+huTCFoosrKJgsybwLrMLyaGaCYeizgPB5OB8zHK8TnlaoRxEnF54tq2PmuOSSuO++PyfUVYN4FRBZuNdqqrG27CRj/kqkgGCIGrpbxTdQLyq/rk7Orr4nNuIAor31Zu6N9Fq5oNWf9UIUvwhk+1sk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773849312; c=relaxed/simple; bh=HHXlaCgpLK4CnyfEuDjmBJL27/ARhpjhY0GBSiU/68M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Iag9nov9jGIKloxZhncRI9CpNjLu4HNMywbI9MX6Y++LHNIEWJcc7f2d9NLVve+WCRT0rvtrZj11x25jm5f5yd8ETfpOWeP70kuqwhz6O/nPQbqSG8NVXhc4vOZD+EiGUiDl+gqpeNaVfLm1olAhRrzpbyzQBwQVa7qcFyPHEfM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B8FA82008; Wed, 18 Mar 2026 08:54:59 -0700 (PDT) Received: from e122027.arm.com (unknown [10.57.61.122]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 40CA83F73B; Wed, 18 Mar 2026 08:55:02 -0700 (PDT) From: Steven Price To: kvm@vger.kernel.org, kvmarm@lists.linux.dev Cc: Steven Price , Catalin Marinas , Marc Zyngier , Will Deacon , James Morse , Oliver Upton , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun , "Aneesh Kumar K . V" , Emi Kisanuki , Vishal Annapurve Subject: [PATCH v13 11/48] arm64: RMI: Define the user ABI Date: Wed, 18 Mar 2026 15:53:35 +0000 Message-ID: <20260318155413.793430-12-steven.price@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260318155413.793430-1-steven.price@arm.com> References: <20260318155413.793430-1-steven.price@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" There is one CAP which identified the presence of CCA, and two ioctls. One ioctl is used to populate memory and the other is used when user space is providing the PSCI implementation to identify the target of the operation. Signed-off-by: Steven Price --- Changes since v12: * Change KVM_ARM_RMI_POPULATE to update the structure with the amount that has been progressed rather than return the number of bytes populated. * Describe the flag KVM_ARM_RMI_POPULATE_FLAGS_MEASURE. * CAP number is bumped. * NOTE: The PSCI ioctl may be removed in a future spec release. Changes since v11: * Completely reworked to be more implicit. Rather than having explicit CAP operations to progress the realm construction these operations are done when needed (on populating and on first vCPU run). * Populate and PSCI complete are promoted to proper ioctls. Changes since v10: * Rename symbols from RME to RMI. Changes since v9: * Improvements to documentation. * Bump the magic number for KVM_CAP_ARM_RME to avoid conflicts. Changes since v8: * Minor improvements to documentation following review. * Bump the magic numbers to avoid conflicts. Changes since v7: * Add documentation of new ioctls * Bump the magic numbers to avoid conflicts Changes since v6: * Rename some of the symbols to make their usage clearer and avoid repetition. Changes from v5: * Actually expose the new VCPU capability (KVM_ARM_VCPU_REC) by bumping KVM_VCPU_MAX_FEATURES - note this also exposes KVM_ARM_VCPU_HAS_EL2! --- Documentation/virt/kvm/api.rst | 65 ++++++++++++++++++++++++++++++++++ include/uapi/linux/kvm.h | 22 ++++++++++++ 2 files changed, 87 insertions(+) diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index fc5736839edd..72a2ce96d1ba 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6553,6 +6553,62 @@ KVM_S390_KEYOP_SSKE Sets the storage key for the guest address ``guest_addr`` to the key specified in ``key``, returning the previous value in ``key``. =20 +4.145 KVM_ARM_VCPU_RMI_PSCI_COMPLETE +------------------------------------ + +:Capability: KVM_CAP_ARM_RMI +:Architectures: arm64 +:Type: vcpu ioctl +:Parameters: struct kvm_arm_rmi_psci_complete (in) +:Returns: 0 if successful, < 0 on error + +:: + + struct kvm_arm_rmi_psci_complete { + __u64 target_mpidr; + __u32 psci_status; + __u32 padding[3]; + }; + +Where PSCI functions are handled by user space, the RMM needs to be inform= ed of +the target of the operation using `target_mpidr`, along with the status +(`psci_status`). The RMM v1.0 specification defines two functions that req= uire +this call: PSCI_CPU_ON and PSCI_AFFINITY_INFO. + +If the kernel is handling PSCI then this is done automatically and the VMM +doesn't need to call this ioctl. + +4.146 KVM_ARM_RMI_POPULATE +-------------------------- + +:Capability: KVM_CAP_ARM_RMI +:Architectures: arm64 +:Type: vm ioctl +:Parameters: struct kvm_arm_rmi_populate (in) +:Returns: 0 on success, < 0 on error + +:: + + struct kvm_arm_rmi_populate { + __u64 base; + __u64 size; + __u64 source_uaddr; + __u32 flags; + __u32 reserved; + }; + +Populate a region of protected address space by copying the data from the +(non-protected) user space pointer provided into a protected region (backe= d by +guestmem_fd). It implicitly sets the destination region to RIPAS RAM. This= is +only valid before any VCPUs have been run. The ioctl might not populate the +entire region and updates the fields `base`, `size` and `source_uaddr`. Us= er +space may have to repeatedly call it until `size` is 0 to populate the ent= ire +region. + +`flags` can be set to `KVM_ARM_RMI_POPULATE_FLAGS_MEASURE` to request that= the +populated data is hashed and added to the guest's Realm Initial Measurement +(RIM). + .. _kvm_run: =20 5. The kvm_run structure @@ -8896,6 +8952,15 @@ helpful if user space wants to emulate instructions = which are not This capability can be enabled dynamically even if VCPUs were already created and are running. =20 +7.47 KVM_CAP_ARM_RMI +-------------------- + +:Architectures: arm64 +:Target: VM +:Parameters: None + +This capability indicates that support for CCA realms is available. + 8. Other capabilities. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 65500f5db379..6ec140ab0ed1 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -985,6 +985,7 @@ struct kvm_enable_cap { #define KVM_CAP_ARM_SEA_TO_USER 245 #define KVM_CAP_S390_USER_OPEREXEC 246 #define KVM_CAP_S390_KEYOP 247 +#define KVM_CAP_ARM_RMI 248 =20 struct kvm_irq_routing_irqchip { __u32 irqchip; @@ -1650,4 +1651,25 @@ struct kvm_pre_fault_memory { __u64 padding[5]; }; =20 +/* Available with KVM_CAP_ARM_RMI, only for VMs with KVM_VM_TYPE_ARM_REALM= */ +#define KVM_ARM_VCPU_RMI_PSCI_COMPLETE _IOW(KVMIO, 0xd6, struct kvm_arm_rm= i_psci_complete) + +struct kvm_arm_rmi_psci_complete { + __u64 target_mpidr; + __u32 psci_status; + __u32 padding[3]; +}; + +/* Available with KVM_CAP_ARM_RMI, only for VMs with KVM_VM_TYPE_ARM_REALM= */ +#define KVM_ARM_RMI_POPULATE _IOWR(KVMIO, 0xd7, struct kvm_arm_rmi_populat= e) +#define KVM_ARM_RMI_POPULATE_FLAGS_MEASURE (1 << 0) + +struct kvm_arm_rmi_populate { + __u64 base; + __u64 size; + __u64 source_uaddr; + __u32 flags; + __u32 reserved; +}; + #endif /* __LINUX_KVM_H */ --=20 2.43.0