From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5A8033CE88; Mon, 3 Aug 2026 11:09:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785755352; cv=none; b=PhCdR70o719Q4hl7OLiIFzGV23E4m15BDp4YV81gdaqH7MZ0eIWpX9WpM1O4cODJ1nzyF1t2FiyI0uYsp0V5kU2qE3aZRZ1GWCUvktmOza2GYsIyyHI/3gSFeidVU+tOGmMAjIu9likIhW6cgGI1HqpSZmjJcHA5AL5g2PkNVGA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785755352; c=relaxed/simple; bh=OJcsICDRY+CinBo36U4IsQPkASDJjVzzFRHNfsgflHE=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=VVBsYy1agasxgL82Q4tcl+MKtuH9XFNRTMarFzegbZ2pFXAgoWrehrJOmxJTGiZtzwKwESB44SwxUkRDobTbITOE5YnoP284X9m82cC/T/OLWmMaNMcnGOAOVHvWPfYTkjomY12eTy+CGnshOQNnj9QfIdCRgv5dahdcSFI1LPw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o1mbL4ei; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="o1mbL4ei" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDC241F000E9; Mon, 3 Aug 2026 11:09:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785755350; bh=mMVTN/10T8H4LBQ9FAgnWWBLcKEifKWIV8qlFsXTsEQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=o1mbL4eideF0EuPtv8xjBjmNnnNf6QudqwYH+T+Oc7TrLiZytw4FyrSayHSYBt/Pc F6OfVaiHEvf29w1U4+NLfxQnXfSbooCXYU6IAz+qfDrPxE3GaH/YaSPzzC5jU1Jp22 oeW/l4LQdfnXF/LE/qHJcrKm9pJEjQovjNpflv6YkrtCqurA3fX7j2A7zoLturznk/ rgHc33JX3PlsXsvrPWB5IdOzcIUD06YB0HBf/phur4AOwLCwQ4khoiPyo+17lYHjRQ 9RrDWSVIMvXx1KjymdLVpzbtMj8EXwISoNzsuLbmIeMfhZQP4VKn2+q1NSiJBzjH9a hsOdAup7l+R6w== 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 1wqqXc-0000000Bj1I-0wpa; Mon, 03 Aug 2026 11:09:08 +0000 Date: Mon, 03 Aug 2026 12:09:07 +0100 Message-ID: <865x1rcvfw.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 Pieralisi Subject: Re: [PATCH v15 15/37] KVM: arm64: CCA: Handle RMI_EXIT_RIPAS_CHANGE In-Reply-To: <20260715142841.80544-16-steven.price@arm.com> References: <20260715142841.80544-1-steven.price@arm.com> <20260715142841.80544-16-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) Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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, lpieralisi@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 15 Jul 2026 15:28:17 +0100, Steven Price wrote: > > The guest can request that a region of its protected address space is > switched between RIPAS_RAM and RIPAS_EMPTY (and back) using > RSI_IPA_STATE_SET. This causes a guest exit with the > RMI_EXIT_RIPAS_CHANGE code. We treat this as a request to convert a > protected region to unprotected (or back), exiting to the VMM to make > the necessary changes to the guest_memfd and memslot mappings. On the > next entry the RIPAS changes are committed by making RMI_RTT_SET_RIPAS > calls. > > The VMM may wish to reject the RIPAS change requested by the guest. For > now it can only do this by no longer scheduling the VCPU as we don't > currently have a usecase for returning that rejection to the guest, but > by postponing the RMI_RTT_SET_RIPAS changes to entry we leave the door > open for adding a new ioctl in the future for this purpose. > > Signed-off-by: Steven Price > --- > Changes since v14: > * Use addition rather than bitwise OR for adding the shared_bit in > realm_unmap_shared_range(), this handles the case where the region > includes the last address (which means 'end' already has the bit > set). > Changes since v13: > * Switch to the new RMI_RTT_UNPROT_UNMAP range-based API. > * Drop ugly hack for RMM bug which errored when the RIPAS was already > set to the desired value. > Changes since v12: > * Switch to the new RMM v2.0 RMI_RTT_DATA_UNMAP which can unmap an > address range. > Changes since v11: > * Combine the "Allow VMM to set RIPAS" patch into this one to avoid > adding functions before they are used. > * Drop the CAP for setting RIPAS and adapt to changes from previous > patches. > Changes since v10: > * Add comment explaining the assignment of rec->run->exit.ripas_base in > kvm_complete_ripas_change(). > Changes since v8: > * Make use of ripas_change() from a previous patch to implement > realm_set_ipa_state(). > * Update exit.ripas_base after a RIPAS change so that, if instead of > entering the guest we exit to user space, we don't attempt to repeat > the RIPAS change (triggering an error from the RMM). > Changes since v7: > * Rework the loop in realm_set_ipa_state() to make it clear when the > 'next' output value of rmi_rtt_set_ripas() is used. > New patch for v7: The code was previously split awkwardly between two > other patches. > --- > arch/arm64/include/asm/kvm_rmi.h | 6 + > arch/arm64/kvm/mmu.c | 8 +- > arch/arm64/kvm/rmi.c | 457 +++++++++++++++++++++++++++++++ > 3 files changed, 468 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/asm/kvm_rmi.h > index b1e4cf0f6803..5461c49bea4d 100644 > --- a/arch/arm64/include/asm/kvm_rmi.h > +++ b/arch/arm64/include/asm/kvm_rmi.h > @@ -104,6 +104,12 @@ int kvm_rec_enter(struct kvm_vcpu *vcpu); > int kvm_rec_pre_enter(struct kvm_vcpu *vcpu); > int handle_rec_exit(struct kvm_vcpu *vcpu, int rec_run_status); > > +void kvm_realm_unmap_range(struct kvm *kvm, > + unsigned long ipa, > + unsigned long size, > + bool unmap_private, > + bool may_block); > + > static inline bool kvm_realm_is_private_address(struct realm *realm, > unsigned long addr) > { > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index cd06881c1497..dcc2ab08d0e4 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -319,6 +319,7 @@ static void invalidate_icache_guest_page(void *va, size_t size) > * @start: The intermediate physical base address of the range to unmap > * @size: The size of the area to unmap > * @may_block: Whether or not we are permitted to block > + * @only_shared: If true then protected mappings should not be unmapped > * I don't understand the need for this additional argument. Given that CCA imposes that shared and private are in non-overlapping ranges, why is it necessary to introduce this at the core of the S2 management code? I'd expect that the CCA code could simply work out what range it needs to run on and keep the API intact. > * Clear a range of stage-2 mappings, lowering the various ref-counts. Must > * be called while holding mmu_lock (unless for freeing the stage2 pgd before > @@ -326,7 +327,7 @@ static void invalidate_icache_guest_page(void *va, size_t size) > * with things behind our backs. > */ > static void __unmap_stage2_range(struct kvm_s2_mmu *mmu, phys_addr_t start, u64 size, > - bool may_block) > + bool may_block, bool only_shared) > { > struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu); > phys_addr_t end = start + size; So what is the *actual* change? M. -- Without deviation from the norm, progress is not possible.