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 788C8C55179 for ; Mon, 3 Aug 2026 11:27:53 +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=/i3CPF5W25MD9Vez/azH6CCKyA9iHKYO0QYhYx2P/Sk=; b=a00zwsPBwIyvucn2nt2ubWjJr7 kx2brUpHPIGTqbMuEd+/7Lrpp/Sx2lYo8rNdzhQNmp+Rp5QNJUQs9ZbgFU0iURh4Aa8y1CH8I3saO rGkxA6F++w+cuQelkgrAFhPjV/abcIJ3WT2bPKjO+ldcX5CHPmJVs27vZWWnhFEPiD60tmEUk93Zn 6Rxy705Wy0j5qU7IMFkRQKnjWRczzyTpDYTyjKmsdY9I+4Wq41nSes6k8C/Pp0+/98JIo0J87c6HC IJ3Dzu7ec78bCR8I9ztt0f9etIdTxw/4VbzJ+tsnQveKN+LT3vH99ceo897DHR2dSpVQm0A0ABXMd qc9DjzzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wqqpZ-0000000GwLx-0OlZ; Mon, 03 Aug 2026 11:27:41 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wqqpX-0000000GwLq-23m0 for linux-arm-kernel@lists.infradead.org; Mon, 03 Aug 2026 11:27:39 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id D965860AA3; Mon, 3 Aug 2026 11:27:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8AD5C1F00A3A; Mon, 3 Aug 2026 11:27:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785756458; bh=/i3CPF5W25MD9Vez/azH6CCKyA9iHKYO0QYhYx2P/Sk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=LD+9R/xv3NSQsat4RjeNlGLbJ1uKDtgjUp+Y/VOu4UnzZ2ojY1qwtPJGndSzD7x8K lJO2raJWfeqkFwlIIirZsXoc4yVV8HGN3aru11ybyaQETHdaNFkrpzObjJ8hpleKRR sLqkS/prEff9LFafonsANPFwmLCSyBgOUxrwJbNlQGXGBn51zNPsMJQTinGYEwGW3w /M93kGzHttMFUxc6+H1QENcytzFLQ+5Mo4ZVzD4rS/i2/X5Zh/0utKRzqfD602lPD9 IYpaPZ3j+Fkp6szxuj6hRSuUaYcWkZH7oLVnzA28McYZZ9gcJeyKVPafXl23m/pmIx fL6aooRlu+2Eg== 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 1wqqpU-0000000BjIT-1j2Y; Mon, 03 Aug 2026 11:27:36 +0000 Date: Mon, 03 Aug 2026 12:27:35 +0100 Message-ID: <864ihbcul4.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 16/37] KVM: arm64: CCA: Handle realm MMIO emulation In-Reply-To: <20260715142841.80544-17-steven.price@arm.com> References: <20260715142841.80544-1-steven.price@arm.com> <20260715142841.80544-17-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, 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 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, 15 Jul 2026 15:28:18 +0100, Steven Price wrote: > > MMIO emulation for a realm cannot be done directly with the VM's > registers as they are protected from the host. However, for emulatable > data aborts, the RMM uses GPRS[0] to provide the read/written value. > We can transfer this from/to the equivalent VCPU's register entry and > then depend on the generic MMIO handling code in KVM. > > For a MMIO read, the value is placed in the shared RecExit structure > during kvm_handle_mmio_return() rather than in the VCPU's register > entry. > > Signed-off-by: Steven Price > Reviewed-by: Gavin Shan > Reviewed-by: Suzuki K Poulose > --- > Changes since v7: > * New comment for rec_exit_sync_dabt() explaining the call to > vcpu_set_reg(). > Changes since v5: > * Inject SEA to the guest is an emulatable MMIO access triggers a data > abort. > * kvm_handle_mmio_return() - disable kvm_incr_pc() for a REC (as the PC > isn't under the host's control) and move the REC_ENTER_EMULATED_MMIO > flag setting to this location (as that tells the RMM to skip the > instruction). > --- > arch/arm64/kvm/inject_fault.c | 4 +++- > arch/arm64/kvm/mmio.c | 16 ++++++++++++---- > arch/arm64/kvm/rmi-exit.c | 15 +++++++++++++++ > 3 files changed, 30 insertions(+), 5 deletions(-) > > diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c > index 89982bd3345f..6492397b73d7 100644 > --- a/arch/arm64/kvm/inject_fault.c > +++ b/arch/arm64/kvm/inject_fault.c > @@ -228,7 +228,9 @@ static void inject_abt32(struct kvm_vcpu *vcpu, bool is_pabt, u32 addr) > > static void __kvm_inject_sea(struct kvm_vcpu *vcpu, bool iabt, u64 addr) > { > - if (vcpu_el1_is_32bit(vcpu)) > + if (unlikely(vcpu_is_rec(vcpu))) > + vcpu->arch.rec.run->enter.flags |= REC_ENTER_FLAG_INJECT_SEA; > + else if (vcpu_el1_is_32bit(vcpu)) > inject_abt32(vcpu, iabt, addr); > else > inject_abt64(vcpu, iabt, addr); Why don't you let inject_dabt64() do its job and reconcile the REC stuff at run time? > diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c > index e2285ed8c91d..a8c125205695 100644 > --- a/arch/arm64/kvm/mmio.c > +++ b/arch/arm64/kvm/mmio.c > @@ -6,6 +6,7 @@ > > #include > #include > +#include > #include > > #include "trace.h" > @@ -138,14 +139,21 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu) > trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr, > &data); > data = vcpu_data_host_to_guest(vcpu, data, len); > - vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data); > + > + if (vcpu_is_rec(vcpu)) > + vcpu->arch.rec.run->enter.gprs[0] = data; > + else > + vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data); This is yet another example of things I do not want to see. KVM works on the GPRs described in the vcpu structure. And that's it. So let the ESR information be correct for CCA, the data being written back to x0, and once you're ready to enter the guest again, copy whatever you need into the CCA data structure. But not any of this stuff. > } > > /* > * The MMIO instruction is emulated and should not be re-executed > * in the guest. > */ > - kvm_incr_pc(vcpu); > + if (vcpu_is_rec(vcpu)) > + vcpu->arch.rec.run->enter.flags |= REC_ENTER_FLAG_EMULATED_MMIO; > + else > + kvm_incr_pc(vcpu); Same thing. kvm_incr_pc() sets a flag. Use that to reconcile the state with CCA. M. -- Without deviation from the norm, progress is not possible.