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 E2CCCC001B0 for ; Thu, 13 Jul 2023 15:54:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=O4MklcB4vVDHCNQxC9WpwsDjTrGGVi52g5FUgF62ZWA=; b=wLOaIXC8B4QVmF DouOmyQMaXCwxw3+L5B/HpKEeTuFAtYhOAhObBJL+xJvsta06WUwPWSVIn1pNJi5SYd+Ch5DrDoW6 DNEpjSDbCMuCddkgGjg4TmuZvKGakzLT4vXdYw0uvPXP79arbBn2WzNYpnIXgCxieLVvyHdZXFya+ 9puKbfqFncJinkKZ8K0oJpbXXuT0Ea1vayFJmA6k6zhJqBd2aEOHEshombag1H901FCVdn5JC5sJ3 Bh6w7plbbTCxtyrcfJdbj3zvOfyz0RyShg4TcMPKMMgLxANVehSYbTifZ2b4xu5ZghPk+egLueppz L2C0SCn1atpbSIprkEZA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qJydY-003plU-06; Thu, 13 Jul 2023 15:53:48 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qJydU-003pkj-1A for linux-arm-kernel@lists.infradead.org; Thu, 13 Jul 2023 15:53:46 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B30B461488; Thu, 13 Jul 2023 15:53:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01FFFC433C7; Thu, 13 Jul 2023 15:53:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689263623; bh=FLps+MVqzmGKj+5TTEFg4RqzcyNptAzC2ai5uQhXZ+A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KWH+Zh8Ch+x/UVfenxc3CGilrLqAVsiM6tooozdLVrp0Im/+jJdoxIvx4+TX/3lZx f7ZZeabTRaaQZFkaHWqGNuRbzw5vt7ItbQeM8GXkOkK+qaWRILWQciLPnXbR2qQS9r V9MSypBdV3F46/gbR1iustT7cyZOdAVBd2aU50VA/y7bBWp2BhQK7CqV1+2roVISC1 vzBB0OCZ/qkw37avlhfNGsVPX+cDVaqNtw8wLw6c+ACbYxv5Vt2SPyARhb0vD7HdH1 CwgO3wtETEXI3Fus9F8yNu6wc3fjfMwaXbjsEat85Onkvb+NXmkAu1XX2NNwTmTA2C ycUEgvPb6io4w== 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 1qJydQ-00CrA6-Gc; Thu, 13 Jul 2023 16:53:40 +0100 Date: Thu, 13 Jul 2023 16:53:40 +0100 Message-ID: <86sf9rvmd7.wl-maz@kernel.org> From: Marc Zyngier To: eric.auger@redhat.com Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Catalin Marinas , Mark Brown , Mark Rutland , Will Deacon , Alexandru Elisei , Andre Przywara , Chase Conklin , Ganapatrao Kulkarni , Darren Hart , Miguel Luis , James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: Re: [PATCH 16/27] KVM: arm64: nv: Add trap forwarding for HCR_EL2 In-Reply-To: <8c32ebdc-a3bc-aabe-5098-3754159d22cd@redhat.com> References: <20230712145810.3864793-1-maz@kernel.org> <20230712145810.3864793-17-maz@kernel.org> <8c32ebdc-a3bc-aabe-5098-3754159d22cd@redhat.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/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: eric.auger@redhat.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, broonie@kernel.org, mark.rutland@arm.com, will@kernel.org, alexandru.elisei@arm.com, andre.przywara@arm.com, chase.conklin@arm.com, gankulkarni@os.amperecomputing.com, darren@os.amperecomputing.com, miguel.luis@oracle.com, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230713_085344_484537_8C3A57C6 X-CRM114-Status: GOOD ( 34.43 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hey Eric, Thanks for looking into this, much appreciated given how tedious it is. On Thu, 13 Jul 2023 15:05:33 +0100, Eric Auger wrote: > > Hi Marc, > > On 7/12/23 16:57, Marc Zyngier wrote: > > Describe the HCR_EL2 register, and associate it with all the sysregs > > it allows to trap. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/emulate-nested.c | 475 ++++++++++++++++++++++++++++++++ > > 1 file changed, 475 insertions(+) > > > > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c > > index 5bab2e85d70c..51901e85e43d 100644 > > --- a/arch/arm64/kvm/emulate-nested.c > > +++ b/arch/arm64/kvm/emulate-nested.c [...] > > + [CGT_HCR_TPC] = { > modern revisions now refer to TPCP, maybe worth a comment? Absolutely. [...] > > + SR_RANGE_TRAP(SYS_ID_PFR0_EL1, > > + sys_reg(3, 0, 0, 7, 7), CGT_HCR_TID3), > in the spec I see this upper limit in the FEAT_FGT section. Out of > curiosity how were you able to convert the sys reg names into this Op0, > Op1, CRn, CRm, Op2. Is there any ordering logic documented somewhere for > those group3 regs? If you look at the sysreg encoding described on page D18-6308 if version J.a of the ARM ARM, you will find a block of 56 contiguous encodings ranging from (3, 0, 0, 1, 0), which happens to be ID_PFR0_EL1, all the way to a reserved range ending in (3, 0, 0, 7, 7). This is the block of register that is controlled by TID3. > I checked Table D18-2 and this looks good but I wonder if there isn't > any more efficient way to review this. Not that I know of, unfortunately. Even the pseudocode isn't enough for this as it doesn't described the trapping of unallocated regions. > > + SR_TRAP(SYS_ICC_SGI0R_EL1, CGT_HCR_IMO_FMO), > > + SR_TRAP(SYS_ICC_ASGI1R_EL1, CGT_HCR_IMO_FMO), > > + SR_TRAP(SYS_ICC_SGI1R_EL1, CGT_HCR_IMO_FMO), > > + SR_RANGE_TRAP(sys_reg(3, 0, 11, 0, 0), > > + sys_reg(3, 0, 11, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 1, 11, 0, 0), > > + sys_reg(3, 1, 11, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 2, 11, 0, 0), > > + sys_reg(3, 2, 11, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 3, 11, 0, 0), > > + sys_reg(3, 3, 11, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 4, 11, 0, 0), > > + sys_reg(3, 4, 11, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 5, 11, 0, 0), > > + sys_reg(3, 5, 11, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 6, 11, 0, 0), > > + sys_reg(3, 6, 11, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 7, 11, 0, 0), > > + sys_reg(3, 7, 11, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 0, 15, 0, 0), > > + sys_reg(3, 0, 15, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 1, 15, 0, 0), > > + sys_reg(3, 1, 15, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 2, 15, 0, 0), > > + sys_reg(3, 2, 15, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 3, 15, 0, 0), > > + sys_reg(3, 3, 15, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 4, 15, 0, 0), > > + sys_reg(3, 4, 15, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 5, 15, 0, 0), > > + sys_reg(3, 5, 15, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 6, 15, 0, 0), > > + sys_reg(3, 6, 15, 15, 7), CGT_HCR_TIDCP), > > + SR_RANGE_TRAP(sys_reg(3, 7, 15, 0, 0), > > + sys_reg(3, 7, 15, 15, 7), CGT_HCR_TIDCP), > > + SR_TRAP(SYS_ACTLR_EL1, CGT_HCR_TACR), > > + SR_TRAP(SYS_DC_ISW, CGT_HCR_TSW), > > + SR_TRAP(SYS_DC_CSW, CGT_HCR_TSW), > > + SR_TRAP(SYS_DC_CISW, CGT_HCR_TSW), > > + SR_TRAP(SYS_DC_IGSW, CGT_HCR_TSW), > > + SR_TRAP(SYS_DC_IGDSW, CGT_HCR_TSW), > > + SR_TRAP(SYS_DC_CGSW, CGT_HCR_TSW), > > + SR_TRAP(SYS_DC_CGDSW, CGT_HCR_TSW), > > + SR_TRAP(SYS_DC_CIGSW, CGT_HCR_TSW), > > + SR_TRAP(SYS_DC_CIGDSW, CGT_HCR_TSW), > > + SR_TRAP(SYS_DC_CIVAC, CGT_HCR_TPC), > I don't see CVADP? Me neither! Good catch! [...] > > + SR_TRAP(SYS_SCTLR_EL1, CGT_HCR_TVM_TRVM), > > + SR_TRAP(SYS_TTBR0_EL1, CGT_HCR_TVM_TRVM), > > + SR_TRAP(SYS_TTBR1_EL1, CGT_HCR_TVM_TRVM), > > + SR_TRAP(SYS_TCR_EL1, CGT_HCR_TVM_TRVM), > > + SR_TRAP(SYS_ESR_EL1, CGT_HCR_TVM_TRVM), > > + SR_TRAP(SYS_FAR_EL1, CGT_HCR_TVM_TRVM), > > + SR_TRAP(SYS_AFSR0_EL1, CGT_HCR_TVM_TRVM),* > Looking at the SFSR0_EL1 MRS/MSR pseudo code I understand TRVM is tested > on read and > TVM is tested on write. However CGT_HCR_TVM has FORWARD_ANY behaviour > while TRVM looks good as FORWARD_READ? Do I miss something. You're not missing anything. For some reason, I had in my head that TVM was trapping both reads and writes, while the spec is clear that it only traps writes. > > > + SR_TRAP(SYS_AFSR1_EL1, CGT_HCR_TVM_TRVM),* > same here and below Yup, I need to fix the TVM encoding like this: @@ -176,7 +176,7 @@ static const struct trap_bits coarse_trap_bits[] = { .index = HCR_EL2, .value = HCR_TVM, .mask = HCR_TVM, - .behaviour = BEHAVE_FORWARD_ANY, + .behaviour = BEHAVE_FORWARD_WRITE, }, [CGT_HCR_TDZ] = { .index = HCR_EL2, [...] > > + /* All _EL2 registers */ > > + SR_RANGE_TRAP(sys_reg(3, 4, 0, 0, 0), > > + sys_reg(3, 4, 10, 15, 7), CGT_HCR_NV), > > + SR_RANGE_TRAP(sys_reg(3, 4, 12, 0, 0), > > + sys_reg(3, 4, 14, 15, 7), CGT_HCR_NV), > > + /* All _EL02, _EL12 registers */ > > + SR_RANGE_TRAP(sys_reg(3, 5, 0, 0, 0), > > + sys_reg(3, 5, 10, 15, 7), CGT_HCR_NV), > > + SR_RANGE_TRAP(sys_reg(3, 5, 12, 0, 0), > > + sys_reg(3, 5, 14, 15, 7), CGT_HCR_NV), > same question as bove, where in the ARM ARM do you find those > ranges? I went over the encoding with a fine comb, and realised that all the (3, 4, ...) encodings are EL2, and all the (3, 5, ...) ones are EL02 and EL12. I appreciate that this is taking a massive bet on the future, but there is no such rule in the ARM ARM as such... > > + SR_TRAP(SYS_SP_EL1, CGT_HCR_NV),* > > + SR_TRAP(OP_AT_S1E2R, CGT_HCR_NV),* > > + SR_TRAP(OP_AT_S1E2W, CGT_HCR_NV),* > > + SR_TRAP(OP_AT_S12E1R, CGT_HCR_NV),* > > + SR_TRAP(OP_AT_S12E1W, CGT_HCR_NV),* > > + SR_TRAP(OP_AT_S12E0R, CGT_HCR_NV),* > according to the pseudo code NV2 is not checked > shouldn't we have a separate CGT? Question also valid for a bunch of ops > below Hmmm. Yes, this is wrong. Well spotted. I guess I need a CGT_HCR_NV_nNV2 for the cases that want that particular condition (NV1 probably needs a similar fix). [...] > CIGDPAE? > CIPAE? These two are part of RME (well, technically MEC, but that an RME thing), and I have no plan to support this with NV -- yet. > CFP/CPP/DVP RCTX? These are definitely missing. I'll add them. Thanks again for going through this list, this is awesome work! M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel