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 AFE92C44501 for ; Wed, 15 Jul 2026 16:23:51 +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=nVtlpmzMXPInWvl/hpKSfGHp45T1wj2acsX8b9iirpc=; b=ZRh2g5Mkl9omfya6X702byk6++ yMZlm2eKyqgEMx+XXpDzE4LcL4LKc18ffn8KZaOXJgfKPM0Z5FrCevYb63yYfUEyKj19Ad/E5HKkN 64X+Qkd9DH4tCqD1gYWB6WQInn6Es+YsG5V2inqOqcKDLICAaxJDEvD+I3LGVUesTvk/ggY5tUaK+ VGvpfI29tVu7uT+fQVTBIn+jlFjl5OWxiVGZ1cpfD9upRLpt4ftt4qVQZF05mqHihiD9xbD7mqQoO kZvJaK3K1p+ssMvE0dePNYGvIn5sZ/ZBIeJBqgfu2rmRqMCPdH/Etq0Pu8umuow/giZq3w0Hc5UeQ hMgcvdIQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wk2Of-0000000FSUi-241S; Wed, 15 Jul 2026 16:23:45 +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 1wk2Od-0000000FSUC-31rl for linux-arm-kernel@lists.infradead.org; Wed, 15 Jul 2026 16:23:43 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 2DD906001D; Wed, 15 Jul 2026 16:23:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D38971F000E9; Wed, 15 Jul 2026 16:23:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784132622; bh=nVtlpmzMXPInWvl/hpKSfGHp45T1wj2acsX8b9iirpc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=aDVnt9vR5KV+6pF4ampF1wEeddjMcxnvrJa7deL8fPo/iuJwSL2loktpEkvS0tFUR 4DHJBCRc5u7gBzgEkLFWIQ8LIHQsaC026PRfA2UzP41Obsig+SkPVH3+YPtyHeSjqd l/uHGnScjmAePG8TQmXwnYWbS0u5AzOkjx1mTgI7k60MCDwHXdWOXdq3UHJDHqIEDL Yng6zHMWUvSMban7bGrFAV7nGTg2YRGDCfWRo0ZKQGBMSzvE1c4OAJ0lNQqYxfqcWP 7Xht9dh7mbE2MupK+R/D2Qn2LBIKODoj7iB8UkRjiVBi9iIRyD3ZDwdIbBcojV69SX YGHE+r9gsEf7w== Received: from [194.56.92.2] (helo=lobster-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 1wk2Oa-00000005OXC-3Yl1; Wed, 15 Jul 2026 16:23:40 +0000 Date: Wed, 15 Jul 2026 17:25:30 +0100 Message-ID: <87y0fc43ut.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 26/37] KVM: arm64: WARN on injected undef exceptions In-Reply-To: References: <20260715142841.80544-1-steven.price@arm.com> <20260715142841.80544-27-steven.price@arm.com> <8733xk5k7v.wl-maz@kernel.org> 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: 194.56.92.2 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 17:15:31 +0100, Steven Price wrote: > > On 15/07/2026 16:46, Marc Zyngier wrote: > > On Wed, 15 Jul 2026 15:28:28 +0100, > > Steven Price wrote: > >> > >> The RMM doesn't allow injection of a undefined exception into a realm > >> guest. Add a WARN to catch if this ever happens. > >> > >> Signed-off-by: Steven Price > >> Reviewed-by: Gavin Shan > >> Reviewed-by: Suzuki K Poulose > >> --- > >> Changes since v6: > >> * if (x) WARN(1, ...) makes no sense, just WARN(x, ...)! > >> --- > >> arch/arm64/kvm/inject_fault.c | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c > >> index 6492397b73d7..613f223bc7a3 100644 > >> --- a/arch/arm64/kvm/inject_fault.c > >> +++ b/arch/arm64/kvm/inject_fault.c > >> @@ -327,6 +327,7 @@ void kvm_inject_size_fault(struct kvm_vcpu *vcpu) > >> */ > >> void kvm_inject_undefined(struct kvm_vcpu *vcpu) > >> { > >> + WARN(vcpu_is_rec(vcpu), "Unexpected undefined exception injection to REC"); > >> if (vcpu_el1_is_32bit(vcpu)) > >> inject_undef32(vcpu); > >> else > > > > No. WARN_ONCE at a push, but even then, this looks dodgy. > > Yep WARN_ONCE() would be better. This function should never be called > for a realm guest. > > > Exceptions must be injectable. Otherwise, how do you respond to, for > > example, a sysreg access for a feature that is hidden from the guest? > > The RMM doesn't allow the host to inject exceptions - with the exception > of SEA after a host-emulated MMIO. > > > Will the RMM perform this in KVM's stead? > > Yes the RMM would have to handle this for the likes of sysreg accesses. > The host doesn't control the trapping of sysreg accesses. There are a > few GIC-related registers which are forwarded to the host ("REC exit due > to system register access") but generally the handling of sysregs is > entirely internal to the RMM. Then the only option is not to just warn, but to mark all realms as dead and refuse to run them any further. If we can't inject an exception and that the RMM isn't doing its job, I can't see how we can continue at all. M. -- Jazz isn't dead. It just smells funny.