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 3AB4DD2ED12 for ; Tue, 20 Jan 2026 14:57:31 +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=u4juXVmRdHndog/gjN1skVewrJuIN9y/AhKiTJnsuXQ=; b=rwqsP1dYVloTh+ygXppWXjd5tN sIxU6ScWmnd81lrvIVTGj3KKBOEan3wzm5DggYdMdJEzyxhlxC4Wo9JoDvBPLt5fhGHYn/7XfO9dM xmcM7kFS4WT7ERPfYMvmBNmmRCXtoMCuzPUcz+w2U4EQ55Y1GSMvEy/qh6y5xcdiQ3Quy4SIXBKB5 GLP7SwmE4J8D8owF0D7rEzdU2obqdlzfR3OixZTcf7VdXIk5/9qm08Dj5QByidDg2lUDJo1BadeSI bBvC7rnhn77kNZHSl8xj9waFSe7VzlxGp7x2+GyEDkJGZtdvWeqoZJHEwNrvRLDclUvVRO0o+x5zG CWDOMc1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1viDAZ-000000042CC-3Tqo; Tue, 20 Jan 2026 14:57:23 +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 1viDAY-000000042Bx-1n0e for linux-arm-kernel@lists.infradead.org; Tue, 20 Jan 2026 14:57:22 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id D8BFB60008; Tue, 20 Jan 2026 14:57:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8FE3CC16AAE; Tue, 20 Jan 2026 14:57:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768921041; bh=Yj7rTjIjMAZ0Wi0ai+L3m3KiOtHRAzqMbeSv8nGF5Pw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=eXOQrxmD9aE1aSJbILqPkFSnLeeTGbtAmBzNsleHo205AckpXoiPSaGU0cWZjUWl5 rFsc0TO+xnGjkm+wrakHzInyFDm+R4OSF1YbU6s1njHQCeYXbtKCq0f6FqBhP44qbG /ndAUdBOjKkxN0852Sl7qARy38Rp4xQ/K828PFjbwUyU6Z6yA1NmjIs94S2N6f/zOa nRovAjKtRUGt4oYONCTOXGgZnTUrHipfk1zTeH+ij5l3Cs4DqM7/wLU3zz3K0t+IUU tiiU0+VL3EDu49Nu0zQAogkuRTMyvqpko4BfyOa1CO4UCnvyGGyJ8E/zR7jjxGGiDt f913JWJ+LqypQ== 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 1viDAV-00000003yyv-0llw; Tue, 20 Jan 2026 14:57:19 +0000 Date: Tue, 20 Jan 2026 14:57:18 +0000 Message-ID: <864iogcoxd.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org Subject: Re: [PATCH v2 3/5] KVM: arm64: Refactor enter_exception64() In-Reply-To: <20251211113828.370370-4-tabba@google.com> References: <20251211113828.370370-1-tabba@google.com> <20251211113828.370370-4-tabba@google.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: tabba@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@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 Thu, 11 Dec 2025 11:38:26 +0000, Fuad Tabba wrote: > > From: Quentin Perret > > To simplify the injection of exceptions into the host in pKVM context, > refactor enter_exception64() to split out the logic for calculating the > exception vector offset and the target CPSR. > > Extract two new helper functions: > - get_except64_offset(): Calculates exception vector offset based on > current/target exception levels and exception type > - get_except64_cpsr(): Computes the new CPSR/PSTATE when taking an > exception > > A subsequent patch will use these helpers to inject UNDEF exceptions > into the host when MTE system registers are accessed with MTE disabled. > Extracting the helpers allows that code to reuse the exception entry > logic without duplicating the CPSR and vector offset calculations. > > No functional change intended. > > Signed-off-by: Quentin Perret > Signed-off-by: Fuad Tabba > --- > arch/arm64/include/asm/kvm_emulate.h | 5 ++ > arch/arm64/kvm/hyp/exception.c | 100 ++++++++++++++++----------- > 2 files changed, 63 insertions(+), 42 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h > index c9eab316398e..c3f04bd5b2a5 100644 > --- a/arch/arm64/include/asm/kvm_emulate.h > +++ b/arch/arm64/include/asm/kvm_emulate.h > @@ -71,6 +71,11 @@ static inline int kvm_inject_serror(struct kvm_vcpu *vcpu) > return kvm_inject_serror_esr(vcpu, ESR_ELx_ISV); > } > > +unsigned long get_except64_offset(unsigned long psr, unsigned long target_mode, > + enum exception_type type); > +unsigned long get_except64_cpsr(unsigned long old, bool has_mte, > + unsigned long sctlr, unsigned long mode); s/cpsr/pstate/ as we don't need to introduce more 32bit terminology. > + > void kvm_vcpu_wfi(struct kvm_vcpu *vcpu); > > void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu); > diff --git a/arch/arm64/kvm/hyp/exception.c b/arch/arm64/kvm/hyp/exception.c > index bef40ddb16db..d3bcda665612 100644 > --- a/arch/arm64/kvm/hyp/exception.c > +++ b/arch/arm64/kvm/hyp/exception.c > @@ -65,12 +65,25 @@ static void __vcpu_write_spsr_und(struct kvm_vcpu *vcpu, u64 val) > vcpu->arch.ctxt.spsr_und = val; > } > > +unsigned long get_except64_offset(unsigned long psr, unsigned long target_mode, > + enum exception_type type) > +{ > + u64 mode = psr & (PSR_MODE_MASK | PSR_MODE32_BIT); > + u64 exc_offset; > + > + if (mode == target_mode) > + exc_offset = CURRENT_EL_SP_ELx_VECTOR; > + else if ((mode | PSR_MODE_THREAD_BIT) == target_mode) > + exc_offset = CURRENT_EL_SP_EL0_VECTOR; > + else if (!(mode & PSR_MODE32_BIT)) > + exc_offset = LOWER_EL_AArch64_VECTOR; > + else > + exc_offset = LOWER_EL_AArch32_VECTOR; > + > + return exc_offset + type; > +} > + > /* > - * This performs the exception entry at a given EL (@target_mode), stashing PC > - * and PSTATE into ELR and SPSR respectively, and compute the new PC/PSTATE. > - * The EL passed to this function *must* be a non-secure, privileged mode with > - * bit 0 being set (PSTATE.SP == 1). > - * > * When an exception is taken, most PSTATE fields are left unchanged in the > * handler. However, some are explicitly overridden (e.g. M[4:0]). Luckily all > * of the inherited bits have the same position in the AArch64/AArch32 SPSR_ELx > @@ -82,50 +95,17 @@ static void __vcpu_write_spsr_und(struct kvm_vcpu *vcpu, u64 val) > * Here we manipulate the fields in order of the AArch64 SPSR_ELx layout, from > * MSB to LSB. > */ > -static void enter_exception64(struct kvm_vcpu *vcpu, unsigned long target_mode, > - enum exception_type type) > +unsigned long get_except64_cpsr(unsigned long old, bool has_mte, > + unsigned long sctlr, unsigned long target_mode) I really dislike the has_mte and sctlr thing. The main reason is that it will not scale as we end-up hiding more feature on the host (think PM and FEAT_EBEP, for example). Even worse, some bits are not necessarily sourced from PSTATE, nor SCTLR (EXLOCK depends on GCSCR_ELx, for example). I think you really need to turn this into something that is flexible enough that it can work for both host and guest, with an actual abstraction. It is likely to look like a list of register accessors to get to the correct data. But it could well be that open-coding it is the least horrid solution. Thanks, M. -- Without deviation from the norm, progress is not possible.