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 8C355C00A8F for ; Tue, 24 Oct 2023 17:25:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229743AbjJXRZm (ORCPT ); Tue, 24 Oct 2023 13:25:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55512 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234857AbjJXRZk (ORCPT ); Tue, 24 Oct 2023 13:25:40 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77DFCD7D for ; Tue, 24 Oct 2023 10:25:37 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20A85C433C8; Tue, 24 Oct 2023 17:25:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698168337; bh=SnWhqOBzSfdQFKc2+NrPePJmpUyCSWtBX0wZvzDayBE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lkoKW8J+yBAbVUuHRsznJ7NJUM0vyd3HTPdO9NHQRh2oS1BQLKS266jIaCrBIuWPa 8cemPvRda423dU7M/m3jkZ/SuM9BY/SxBv00jxHMO94kuQ5EW48ZyIM3pQgvgqjpj6 Mff08eWSBDXdOsEprA4vs1GcEE50Wt7z+X5P1kFSOyyC7RnuWK9KAQy4isGA6Cg/ZY FJKlLGR4OrtDCKSPsd9+aVTMgLJCxRIc0mOx33qvgeo/Zb857HspXgzZbSADS3Ug/W fZFzCQ+EbqIT/maTBWpgnayzsUqczNYIEBuztSC10nVjCZyYC5jPDgl0XmNpD/jKzs Sg90Q7QBHdsLA== 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 1qvL9q-007Iu3-9e; Tue, 24 Oct 2023 18:25:34 +0100 Date: Tue, 24 Oct 2023 18:25:33 +0100 Message-ID: <86jzrc3pbm.wl-maz@kernel.org> From: Marc Zyngier To: Miguel Luis Cc: "kvmarm@lists.linux.dev" , "kvm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Eric Auger , Oliver Upton , 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: <7DD05DC0-164E-440F-BEB1-E5040C512008@oracle.com> References: <20231023095444.1587322-1-maz@kernel.org> <20231023095444.1587322-6-maz@kernel.org> <7DD05DC0-164E-440F-BEB1-E5040C512008@oracle.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/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: miguel.luis@oracle.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, eric.auger@redhat.com, oliver.upton@linux.dev, 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 Mon, 23 Oct 2023 19:55:10 +0100, Miguel Luis wrote: >=20 > Hi Marc, >=20 > > On 23 Oct 2023, at 09:54, Marc Zyngier wrote: > >=20 > > When trapping accesses from a NV guest that tries to access > > SPSR_{irq,abt,und,fiq}, make sure we handle them as RAZ/WI, > > as if AArch32 wasn't implemented. > >=20 > > This involves a bit of repainting to make the visibility > > handler more generic. > >=20 > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/include/asm/sysreg.h | 4 ++++ > > arch/arm64/kvm/sys_regs.c | 16 +++++++++++++--- > > 2 files changed, 17 insertions(+), 3 deletions(-) > >=20 > > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/s= ysreg.h > > index 4a20a7dc5bc4..5e65f51c10d2 100644 > > --- a/arch/arm64/include/asm/sysreg.h > > +++ b/arch/arm64/include/asm/sysreg.h > > @@ -505,6 +505,10 @@ > > #define SYS_SPSR_EL2 sys_reg(3, 4, 4, 0, 0) > > #define SYS_ELR_EL2 sys_reg(3, 4, 4, 0, 1) > > #define SYS_SP_EL1 sys_reg(3, 4, 4, 1, 0) > > +#define SYS_SPSR_irq sys_reg(3, 4, 4, 3, 0) > > +#define SYS_SPSR_abt sys_reg(3, 4, 4, 3, 1) > > +#define SYS_SPSR_und sys_reg(3, 4, 4, 3, 2) > > +#define SYS_SPSR_fiq sys_reg(3, 4, 4, 3, 3) > > #define SYS_IFSR32_EL2 sys_reg(3, 4, 5, 0, 1) > > #define SYS_AFSR0_EL2 sys_reg(3, 4, 5, 1, 0) > > #define SYS_AFSR1_EL2 sys_reg(3, 4, 5, 1, 1) > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index 0071ccccaf00..be1ebd2c5ba0 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -1791,8 +1791,8 @@ static unsigned int el2_visibility(const struct k= vm_vcpu *vcpu, > > * HCR_EL2.E2H=3D=3D1, and only in the sysreg table for convenience of > > * handling traps. Given that, they are always hidden from userspace. > > */ > > -static unsigned int elx2_visibility(const struct kvm_vcpu *vcpu, > > - const struct sys_reg_desc *rd) > > +static unsigned int hidden_user_visibility(const struct kvm_vcpu *vcpu, > > + const struct sys_reg_desc *rd) > > { > > return REG_HIDDEN_USER; > > } > > @@ -1803,7 +1803,7 @@ static unsigned int elx2_visibility(const struct = kvm_vcpu *vcpu, > > .reset =3D rst, \ > > .reg =3D name##_EL1, \ > > .val =3D v, \ > > - .visibility =3D elx2_visibility, \ > > + .visibility =3D hidden_user_visibility, \ > > } > >=20 > > /* > > @@ -2387,6 +2387,16 @@ static const struct sys_reg_desc sys_reg_descs[]= =3D { > > EL2_REG(ELR_EL2, access_rw, reset_val, 0), > > { SYS_DESC(SYS_SP_EL1), access_sp_el1}, > >=20 > > + /* AArch32 SPSR_* are RES0 if trapped from a NV guest */ > > + { SYS_DESC(SYS_SPSR_irq), .access =3D trap_raz_wi, > > + .visibility =3D hidden_user_visibility }, > > + { SYS_DESC(SYS_SPSR_abt), .access =3D trap_raz_wi, > > + .visibility =3D hidden_user_visibility }, > > + { SYS_DESC(SYS_SPSR_und), .access =3D trap_raz_wi, > > + .visibility =3D hidden_user_visibility }, > > + { SYS_DESC(SYS_SPSR_fiq), .access =3D trap_raz_wi, > > + .visibility =3D hidden_user_visibility }, > > + >=20 > I=E2=80=99m trying to understand this patch and its surroundings. >=20 > Those SPSR_* registers UNDEF at EL0. I do not understand > why use REG_HIDDEN_USER instead of REG_HIDDEN. USER here means host userspace, not guest EL0. That's because the various SPSR_* registers are already visible from userspace as KVM_REG_ARM_CORE_REG(spsr[KVM_SPSR_*]), and the above entries are solely for the purpose of handling a trap (and thus must not be exposed in the list of available sysregs). This is similar to what we are doing for the ELx2 registers, which are already exposed as EL0/EL1 registers. > 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 ? 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. M. --=20 Without deviation from the norm, progress is not possible.