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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39999C0032E for ; Wed, 25 Oct 2023 08:28:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234031AbjJYI2L (ORCPT ); Wed, 25 Oct 2023 04:28:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232657AbjJYI2K (ORCPT ); Wed, 25 Oct 2023 04:28:10 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D720129 for ; Wed, 25 Oct 2023 01:28:08 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1C98C433C7; Wed, 25 Oct 2023 08:28:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698222487; bh=UY0O5Oq2DKoxmwft8A1Grn8A24oCZUcBh+4pH3tffpo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MtBDBCT3hbyiq7WRPmBD+sI4N60Z67hN34pqxPE3ImGa2v/vhkVWZPIcCC70tukkn CFzUUsv3hw1JyvKR3b/5nF7Ar82G7Xh9wUAuwWumOu4qsItBvRJga/5KsRotD0fIH2 cfloGpc5n5SK8zbO/NMApfoIkjBRPoSjaVK1fyQdB0L5R8xhLJ8XN1rHGY8GvfP0Tm TOukooN79oMiDmL2c0G3Wrs8qwA4yhgcTkMWA3BKO2j3brOd21l9cSQEfNXZs9ngfN mPb2tt4QpEQQBVJQCyd6Y18fYV6M1r6z40CpDt7R4fq3x7YtimQ5wixSowaHWePeGC +3KsQ8bTdDrSw== 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.95) (envelope-from ) id 1qvZFE-007TeE-Ug; Wed, 25 Oct 2023 09:28:05 +0100 Date: Wed, 25 Oct 2023 09:28:03 +0100 Message-ID: <86h6mf3y3w.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: Miguel Luis , "kvmarm@lists.linux.dev" , "kvm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Eric Auger , James Morse , Suzuki K Poulose , Zenghui Yu Subject: Re: [PATCH 5/5] KVM: arm64: Handle AArch32 SPSR_{irq,abt,und,fiq} as RAZ/WI In-Reply-To: References: <20231023095444.1587322-1-maz@kernel.org> <20231023095444.1587322-6-maz@kernel.org> <7DD05DC0-164E-440F-BEB1-E5040C512008@oracle.com> <86jzrc3pbm.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/29.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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, miguel.luis@oracle.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, eric.auger@redhat.com, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, 25 Oct 2023 00:04:27 +0100, Oliver Upton wrote: >=20 > On Tue, Oct 24, 2023 at 10:41:57PM +0000, Oliver Upton wrote: > > On Tue, Oct 24, 2023 at 06:25:33PM +0100, Marc Zyngier wrote: > > > On Mon, 23 Oct 2023 19:55:10 +0100, Miguel Luis wrote: > > > > Also, could you please explain what is happening at PSTATE.EL =3D= =3D EL1 > > > > and if EL2Enabled() && HCR_EL2.NV =3D=3D =E2=80=981=E2=80=99 ? > > >=20 > > > We directly take the trap and not forward it. This isn't exactly the > > > letter of the architecture, but at the same time, treating these > > > registers as RAZ/WI is the only valid implementation. I don't > > > immediately see a problem with taking this shortcut. > >=20 > > Ugh, that's annoying. The other EL2 views of AArch32 state UNDEF if EL1 > > doesn't implement AArch32. It'd be nice to get a relaxation in the > > architecture to allow an UNDEF here. >=20 > Correction (I wasn't thinking): RES0 behavior should be invariant, much > like the UNDEF behavior of the other AA32-specific registers. I'm not sure what you're asking for exactly here, so let me explain my understanding of the architecture on this point, which is that the *32_EL2 registers are different in nature from the SPSR_* registers. IFAR32_EL2 and co are accessors for the equivalent AArch32 registers. If AArch32 isn't implemented, then these registers should UNDEF, because there is nothing to access at all. The status of SPSR_* is more subtle: the AArch32 exception model is banked (irq, fiq, abt, und), and for each bank we have a triplet (LR_*, SP_*, SPSR_*), plus the extra R[8-12]_fiq. On taking an exception from AArch32 EL1 to AArch64 EL2, all the (LR_*, SP_*, R*_fiq) are stored as part of the AArch64 GPRs (X16-X30, see I_PYKVS). And what about SPSR_*? Well, they live as extra registers that are populated on exception entry. But they are similar in nature to the GPRs that store the rest of the stuff. When AArch32 isn't implemented, the natural choice is to keep them around, only as RES0, because they are just GPRs. Of course, all of this is an architectural choice. If I had to change anything, I'd rather have everything to UNDEF. But there is some logic in the madness. And frankly, we will never see an AArch32-capable, NV-capable HW implementation ever, so this is all fairly academic. Cheers, M. --=20 Without deviation from the norm, progress is not possible.