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 C6FC8C001B0 for ; Mon, 7 Aug 2023 12:41:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231625AbjHGMlG (ORCPT ); Mon, 7 Aug 2023 08:41:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40376 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230175AbjHGMlF (ORCPT ); Mon, 7 Aug 2023 08:41:05 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 753BF170B for ; Mon, 7 Aug 2023 05:40:46 -0700 (PDT) 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 544CD619C4 for ; Mon, 7 Aug 2023 12:40:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA53EC433C7; Mon, 7 Aug 2023 12:40:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691412044; bh=RsAY8F/KSwqORT8NHwkg0CSFj0ZY5rAKG23RDmdDLzY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jRd9+oTOceOVTrrj62l+cpv5OGndVY4+EeBfYYSdMf9yzbc/uK8Q/roDA+nktJT99 dFwkYbhHozVgsGwjuWpz0kG70pKRv6zo4kYDNpuHOB+ZSRdEdr99jayUz0pcKXWrVq MtiGqtNAN/pxxqh0+ya7/Wcv6uSZIaLgboracqBonKUTOYbsQZA/6VaxH0kqUHTAbm OvnVvErTUwOg8kPIr0yL6kLrhfwKRN9hCBXPvWfRg8eDIzn71f3I8WvwxiQR+meLT6 f1OV1Dy7ivYWD3+aM8lj+cHomUmj2jqghsvcM5mQsazmYc63H5gsYDsb0/EFpS1uvD /Z+iiVREW9bYQ== 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 1qSzXO-002pS2-5r; Mon, 07 Aug 2023 13:40:42 +0100 Date: Mon, 07 Aug 2023 13:40:34 +0100 Message-ID: <868ran58l9.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" , Catalin Marinas , Eric Auger , Mark Brown , Mark Rutland , Will Deacon , Alexandru Elisei , Andre Przywara , Chase Conklin , Ganapatrao Kulkarni , Darren Hart , James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: Re: [PATCH v2 06/26] arm64: Add debug registers affected by HDFGxTR_EL2 In-Reply-To: References: <20230728082952.959212-1-maz@kernel.org> <20230728082952.959212-7-maz@kernel.org> <61B845D3-A42B-451F-B74D-51B4A1FD28C6@oracle.com> <86leet5o20.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/28.2 (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, catalin.marinas@arm.com, eric.auger@redhat.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, 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 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 03 Aug 2023 01:00:52 +0100, Miguel Luis wrote: >=20 > Hi Marc, >=20 > > On 2 Aug 2023, at 17:52, Marc Zyngier wrote: > >=20 > > On Mon, 31 Jul 2023 17:41:41 +0100, > > Miguel Luis wrote: > >>=20 > >> Hi Marc, > >>=20 > >> A few comments on this one, please see below. > >>=20 > >>> On 28 Jul 2023, at 08:29, Marc Zyngier wrote: > >>>=20 > >>> The HDFGxTR_EL2 registers trap a (huge) set of debug and trace > >>> related registers. Add their encodings (and only that, because > >>> we really don't care about what these registers actually do at > >>> this stage). > >>>=20 > >>> Signed-off-by: Marc Zyngier > >>> --- > >>> arch/arm64/include/asm/sysreg.h | 78 +++++++++++++++++++++++++++++++++ > >>> 1 file changed, 78 insertions(+) > >>>=20 > >>> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm= /sysreg.h > >>> index 76289339b43b..9dfd127be55a 100644 > >>> --- a/arch/arm64/include/asm/sysreg.h > >>> +++ b/arch/arm64/include/asm/sysreg.h > >>> @@ -194,6 +194,84 @@ > >>> #define SYS_DBGDTRTX_EL0 sys_reg(2, 3, 0, 5, 0) > >>> #define SYS_DBGVCR32_EL2 sys_reg(2, 4, 0, 7, 0) > >>>=20 > >>> +#define SYS_BRBINF_EL1(n) sys_reg(2, 1, 8, (n & 15), (((n & 16) >> 2= ) | 0)) > >>> +#define SYS_BRBINFINJ_EL1 sys_reg(2, 1, 9, 1, 0) > >>> +#define SYS_BRBSRC_EL1(n) sys_reg(2, 1, 8, (n & 15), (((n & 16) >> 2= ) | 1)) > >>> +#define SYS_BRBSRCINJ_EL1 sys_reg(2, 1, 9, 1, 1) > >>> +#define SYS_BRBTGT_EL1(n) sys_reg(2, 1, 8, (n & 15), (((n & 16) >> 2= ) | 2)) > >>> +#define SYS_BRBTGTINJ_EL1 sys_reg(2, 1, 9, 1, 2) > >>> +#define SYS_BRBTS_EL1 sys_reg(2, 1, 9, 0, 2) > >>> + > >>> +#define SYS_BRBCR_EL1 sys_reg(2, 1, 9, 0, 0) > >>> +#define SYS_BRBFCR_EL1 sys_reg(2, 1, 9, 0, 1) > >>> +#define SYS_BRBIDR0_EL1 sys_reg(2, 1, 9, 2, 0) > >>> + > >>> +#define SYS_TRCITECR_EL1 sys_reg(3, 0, 1, 2, 3) > >>> +#define SYS_TRCITECR_EL1 sys_reg(3, 0, 1, 2, 3) > >>=20 > >> SYS_TRCITECR_EL1 shows up twice. > >=20 > > Ah, nice one. Too many registers. > >=20 > >>=20 > >>> +#define SYS_TRCACATR(m) sys_reg(2, 1, 2, ((m & 7) << 1), (2 | (m >> = 3))) > >>=20 > >> Besides m=E2=80=99s restrictions it could be sanitised in op2 to consi= der only bit m[3]. > >> Suggestion for op2: (2 | ((m & 8) >> 3))) > >=20 > > It is fully expected that 'm' will be in the 0-15 range, as per the > > architecture (D19.4.8), and the tables only use that exact range. > >=20 > > Do you see an actual bug, or is this defensive programming? > >=20 >=20 > I was seeing a problem when m[5]=3D1 then Op2 of 0b01:m[3] isn=E2=80=99t = guaranteed > anymore overridden with 0b11:m[3]. But that'd be wrong anyway. Now, we'd have an encoding that possibly aliases to something else, and we don't know about it. > Clearly =E2=80=98m=E2=80=99 would be outside the range but not messing wi= th Op2 fixed bits 0b01. > Not a problem for patch 21 though. All these macros have as the basis for their use that you use *valid* input. > Due to the uncertainty if this can bite later, hence the suggestion and a= lso > open to advices. If you really want some defensive programming on that front, then you should make sure we detect the issue at compile time, rather than silently changing the encoding. Thanks, M. --=20 Without deviation from the norm, progress is not possible.