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 AD4CBEA4E07 for ; Mon, 2 Mar 2026 14:25:48 +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=mALrw1eLH641PMlMGV5CJ+/tyimstfqkzeMzQzYlWZw=; b=WklP97IxIFZmlgypnLG3Tde2gc hBTYdfo/W556XdjcUw64auiBOmaCJwPunlXhlCKfgzPmSgUjwXwWT0zPDP/g9FfzaKFC7rDv9s/H+ GUzHfyeGucd32C9M7tAPKl0Gf9Njg8k02QEXQfF+dCb//uFB4ZcG5HMJ9sEF6iTawEH0S1qk+MqS0 qOpWA+eQHhDKvW0KQNw/fq43Bx+sY3cuQwsQOWQMYAqyXVwYxa1exc+dSndWrQEdnYyye4GO9TJ+u zm3qqtfVjWFYK5I5w1ehoCZE0qL5LDXMIXTZJo0yrh+2T7+P5GTT5Y9v/LROhFJ+6ArNsuEl/qHHv 1kj0wG8w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vx4DO-0000000DENQ-4Awl; Mon, 02 Mar 2026 14:25:43 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vx4DO-0000000DENK-08Q3 for linux-arm-kernel@lists.infradead.org; Mon, 02 Mar 2026 14:25:42 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 0E86A600C4; Mon, 2 Mar 2026 14:25:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB7C0C19423; Mon, 2 Mar 2026 14:25:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772461540; bh=5XDiqS4aSa5oC2UuISF+9AW9hAYh/GZv5E3lc65T4uc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oOFMmDn87wu4l7gzys50haVeiBkImmxEMtScj3uKhiIYYZtOnPd5AP8biFi62yFHS d681BrkYEuw4CE0DQW7uvmFT2ehaO/i4KgCx6LJKN7a5XM93dNqEj2eGTiotJAXruG J6m2hl+rq7UFPISzpOqDDGCTxnwqiR3ekewREzTGWF4zIX98fpkc+MPgG8+RkclSpe 8sAvMxRNy4ajTIjIb08oh1xYVy/AqJOgll9q9GyvfuOXmPMnJX2DdtfY9wSQpQHdoz mBgATrDb1vm3H44DFllUC7N/mylvQoi+mchHoZVRNwtZG9B8b0tUUY/mw9lBgkQ8JM ef9+kMXGFeW+g== 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 1vx4DK-0000000FGwW-21PP; Mon, 02 Mar 2026 14:25:38 +0000 Date: Mon, 02 Mar 2026 14:25:37 +0000 Message-ID: <86tsuy8g0u.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 Subject: Re: [PATCH v12 06/46] arm64: RMI: Define the user ABI In-Reply-To: <20251217101125.91098-7-steven.price@arm.com> References: <20251217101125.91098-1-steven.price@arm.com> <20251217101125.91098-7-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 X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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, 17 Dec 2025 10:10:43 +0000, Steven Price wrote: > > 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 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 | 57 ++++++++++++++++++++++++++++++++++ > include/uapi/linux/kvm.h | 23 ++++++++++++++ > 2 files changed, 80 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 01a3abef8abb..2d5dc7e48954 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -6517,6 +6517,54 @@ the capability to be present. > > `flags` must currently be zero. > > +4.144 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 informed of > +the target of the operation using `target_mpidr`, along with the status > +(`psci_status`). The RMM v1.0 specification defines two functions that require > +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. Shouldn't we make handling of PSCI mandatory for VMMs that deal with CCA? I suspect it would simplify the implementation significantly. What vcpu fd does this apply to? The vcpu calling the PSCI function? Or the target? This is pretty important for PSCI_ON. My guess is that this is setting the return value for the caller? Assuming this is indeed for the caller, why do we have a different flow from anything else that returns a result from a hypercall? > + > +4.145 KVM_ARM_RMI_POPULATE > +-------------------------- > + > +:Capability: KVM_CAP_ARM_RMI > +:Architectures: arm64 > +:Type: vm ioctl > +:Parameters: struct kvm_arm_rmi_populate (in) > +:Returns: number of bytes populated, < 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 user > +space pointer provided. This is only valid before any VCPUs have been run. > +The ioctl might not populate the entire region and user space may have to > +repeatedly call it (with updated pointers) to populate the entire region. size as a __u64 is odd, as the return value from the ioctl is a signed int. This implies that you can't really report how many bytes you have copied. Some form of consistency wouldn't hurt. Thanks, M. -- Without deviation from the norm, progress is not possible.