From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EC579CD5BD5 for ; Wed, 27 May 2026 15:21:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=zfzKYqdLKqLou2xyyPcBQZmXad6Js16rghPX85JNlC8=; b=gX50KWXA2VB4A/msIpzq/poFoR GuR6YeFeAI0y7YwbgsBqWpdMc0fOQqExWv8PalGW2/Ci5N9FeOvvjop0ZMRw58eDAwNowPYSAIQp2 wLhx9ErBEpvwJpGjJIzGd1pM2YwJETEIFcnfz2qYO0kDfLVu7nAbmuU5P83kjSv7TEKwESa/CcaDl vDH1BLAvybzNSbj7MYFQB86PUDrNTARPjZyqh0L2GmxjgZZ2J8UyAGM0merhfu8K+0fPD9zp084XF WcvnYenewV3e+PT31f9wkfD/z/D0fIQhoyIlwHhkvafoJM/8YrzMyRfvNMnGe2d3D1jCUhIN0Qz0K IzrVgBFw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wSG4g-00000004OnI-1DZC; Wed, 27 May 2026 15:21:38 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wSG4d-00000004OmZ-40vk for linux-arm-kernel@lists.infradead.org; Wed, 27 May 2026 15:21:37 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 6D18F43D84; Wed, 27 May 2026 15:21:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C3C11F000E9; Wed, 27 May 2026 15:21:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779895295; bh=zfzKYqdLKqLou2xyyPcBQZmXad6Js16rghPX85JNlC8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=bqKm/KIx9SZiNFvg+rRpM9FW+apfluy74behCm+gNm7zPh7TFNXNfkZcXFxlFkUXR 75HJ325gNQJZ3eAVBm06XNdT8uXEB5lo5l2yZMiAJhfqKU9jiqvn1S2mECrepBDhHC QFdJee5SKkaZ6Htu401Go8q+AP0zROI8I94tc4MTUoD8brfWJrjzkVetrh52AHHaqS 4e5uGQ5LFWCoFKYw7idtizfjriz5gVd2E/MVjBTFKsunebdNF0tWw7mbnDuzkWPAHn 0cohXt53o9ybwk6hc0rS00bSwBp+8dMNOroAMfW1ENaVFhYu1QzSUb6Qbc2lVq0jB9 /syB2Qilfkk1A== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wSG4b-00000006jaR-1Cqt; Wed, 27 May 2026 15:21:33 +0000 Date: Wed, 27 May 2026 16:21:32 +0100 Message-ID: <86jysovpxf.wl-maz@kernel.org> From: Marc Zyngier To: Steven Price Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , 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 , WeiLin.Chang@arm.com, Lorenzo.Pieralisi2@arm.com Subject: Re: [PATCH v14 13/44] arm64: RMI: Define the user ABI In-Reply-To: <20260513131757.116630-14-steven.price@arm.com> References: <20260513131757.116630-1-steven.price@arm.com> <20260513131757.116630-14-steven.price@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: steven.price@arm.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, james.morse@arm.com, oliver.upton@linux.dev, suzuki.poulose@arm.com, yuzenghui@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, joey.gouly@arm.com, alexandru.elisei@arm.com, christoffer.dall@arm.com, tabba@google.com, linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com, gshan@redhat.com, sdonthineni@nvidia.com, alpergun@google.com, aneesh.kumar@kernel.org, fj0570is@fujitsu.com, vannapurve@google.com, WeiLin.Chang@arm.com, Lorenzo.Pieralisi2@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260527_082136_037740_339435A5 X-CRM114-Status: GOOD ( 37.60 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 13 May 2026 14:17:21 +0100, Steven Price wrote: > > There is one CAP which identified the presence of CCA, and one ioctl. > The ioctl is used to populate memory during creation of the realm as > this requires the RMM to copy data from an unprotected address to the > protected memory - CCA does not support memory conversion where the > memory contents is preserved as this is incompatible with memory > encryption. > > Signed-off-by: Steven Price > --- > Changes since v13: > * KVM_ARM_VCPU_RMI_PSCI_COMPLETE removed. > * KVM_ARM_RMI_POPULATE documentation updated to reflect that the > structure is written by the kernel. > * CAP number bumped. > 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 | 40 ++++++++++++++++++++++++++++++++++ > include/uapi/linux/kvm.h | 13 +++++++++++ > 2 files changed, 53 insertions(+) $SUBJECT looks wrong. This is a KVM change, not an RMI change. > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 52bbbb553ce1..ca68aae7faa2 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -6553,6 +6553,37 @@ 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``. > > +4.145 KVM_ARM_RMI_POPULATE > +-------------------------- > + > +:Capability: KVM_CAP_ARM_RMI > +:Architectures: arm64 > +:Type: vm ioctl > +:Parameters: struct kvm_arm_rmi_populate (in/out) > +: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 (backed 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 in this case the kernel updates the fields `base`, `size` and > +`source_uaddr`. User space may have to repeatedly call it until `size` is 0 to > +populate the entire 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). Where is that measurement stored? And retrieved? At least a pointer to that would help. > + > .. _kvm_run: > > 5. The kvm_run structure > @@ -8904,6 +8935,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. > > +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. > ====================== > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 6c8afa2047bf..b8cff0938041 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -996,6 +996,7 @@ struct kvm_enable_cap { > #define KVM_CAP_S390_USER_OPEREXEC 246 > #define KVM_CAP_S390_KEYOP 247 > #define KVM_CAP_S390_VSIE_ESAMODE 248 > +#define KVM_CAP_ARM_RMI 249 > > struct kvm_irq_routing_irqchip { > __u32 irqchip; > @@ -1669,4 +1670,16 @@ struct kvm_pre_fault_memory { > __u64 padding[5]; > }; > > +/* 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_populate) > +#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 */ Thanks, M. -- Without deviation from the norm, progress is not possible.