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 F4015409604; Mon, 3 Aug 2026 11:27:38 +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=1785756460; cv=none; b=mN6yBQbxMz2yix1wHcAqrdU2wbksO9sW1JpDDqYqaWVpyu/bY2WVt5rLCntv0kx5+YdtiprNcxN+8MxT2S81snT4x7kvKjjNVlvVyZ/K62fbiwLqj2bDxLQd2DWJw7YHob+rcZ3AvqLTjFE8xRmSdWaIZHo3mvbT9sq4aqo4Wwk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785756460; c=relaxed/simple; bh=Lef4IQuLjnebR5p/FsvALUdCAtneo6dIdEQCYmWVXZU=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=VEu/mQYxjPstCMnBOpJfgeswrQ2+GuYSGtAJmLhJcSsBdOqqXd4/OP2HYo9ohwEyvHjHfeshqUVnc0f7r8B3qWjJWyFECqAgfG4JBrbHfV1LQZLQ2e+Kbd4aWEc7YYgpGipvv/3iiJdrN0e5I7nTtXUIWx4SsYn0Y/zTkgYvPJQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LD+9R/xv; 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="LD+9R/xv" 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) 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: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.