Received: by 2002:a89:413:0:b0:1fd:dba5:e537 with SMTP id m19csp774685lqs; Fri, 14 Jun 2024 05:34:25 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXKu1X4zzNDIQPBunby3fgB1UqzzukzurvKj7soOFdjVoG/h4D8Pv9qIfAeIJySZ3Ls+KrvUrVaKXPZVFC30ypPV+Jl1yAx/P36TbkrNQ== X-Google-Smtp-Source: AGHT+IGzztTL3htSeWlmEcTwsF/Nps0RHnk1Jv5VHuov6kCnr7/R8ZYcZtk71LhX7+A03bTR8s/T X-Received: by 2002:a05:6870:ac2b:b0:24f:db4a:bc02 with SMTP id 586e51a60fabf-25842be93d4mr2530374fac.52.1718368465111; Fri, 14 Jun 2024 05:34:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1718368465; cv=pass; d=google.com; s=arc-20160816; b=KNIMHo0mM9QJTEP80+Ky7h2PSPpRY5aBkXki4z9vtrkPUthDK4IOYe4iIBq33SMVHi BW85iZrtztu5XpBMOYoyAw/wEPVOapr92MFjs5kesO4/Oj1inDiKymEIARYr0v5GwEzy tAuEgjfF+pxLlJFuyIuGpvro6TzYUxoskF1G4AkLVpv6f56KDXUvG9WD/XMNZxgxkbyv 8a5KXHcAlEg1Z9y+S/FCrJGPAPuU7OHR2CC+bhewSbqoQDQCiShgDXhQ65L3RBv6Wab4 lsv1rr0fH12eULx1tAZDd4iP2TAIGaz+D77cE8NKYrRZOawFKcwZyM2h65czA1fTt94J 7pvg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :user-agent:references:in-reply-to:subject:cc:to:from:message-id :date:dkim-signature; bh=+sQUHOKBg9f5WD32tQXdjMYCYk53wEsIWDlztiGvc9I=; fh=MualLUEgSTyoTxSPxizY4L9ZPpNq/c8zmiKP0BtA4kU=; b=vG2zY0w+ANgLf3s9+t0bjT8r/ZyC1WxgrVH+Bz7os1eCcnK8Hyh1f08UrdgdMXt3u2 8X3n9mbDgtNAviYVw7rad8p9B/O8ObSYjCDVLjGYcclwxCC6kbUcg6/aCl5M7Q+UxgQt AErJk7cYskeVeBp93gyhGLqdddn8aB9iAVDGbRu3EY+CiaANJPBZ9n1lAMGpF38SceQV LW3HobgRXEXCpzW+JkB5ViCiVR5tkVzjCE3eT8UB5tbBJt3ne5v/1UcrVxgfKWtSaBmK xhXMdNUS5z+TuJO22gv5QbllUsboioBPnz5ozbOK+B60jelK2d28KQ5K1MsbVWSO5r0Y Nvyg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=rcvHrAOq; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-214900-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-214900-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id d2e1a72fcca58-705ccb3e462si3473837b3a.200.2024.06.14.05.34.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Jun 2024 05:34:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-214900-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=rcvHrAOq; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-214900-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-214900-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id E6FD5284367 for ; Fri, 14 Jun 2024 12:33:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0349B198A27; Fri, 14 Jun 2024 12:33:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rcvHrAOq" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E031A14D29B; Fri, 14 Jun 2024 12:33:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718368420; cv=none; b=bj496EQ0uqQfhpuMF3LH8EquAjZfaL48fREU57feuPWuC/lx8ROPVDlcgnkDurTYJsHIpot6roCJtNHDGjad0TiNtBt9U1lq6B45zzptqI1cgS3Ae1uH4a/eKY5GuKz8VF+E4ckFhKQ6nS+LPU1uH/5gdOTifhw7b8K87kY1eYk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718368420; c=relaxed/simple; bh=GLgMoYqQYcCbuXGoGXD8j9JN7q1v3yKblwBp8qWBNDg=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=SfsyXCtVV+KOCKAGXa8kcY4BxE/9lbmtG4EAie1ic9X0REKthLFmWaSZ6BPo4H+jFOmPCPkj6tPgdcI6Ra4T3ahnaAD6js9IlA9gyA8PuK4hrAAX9fNBT1V3mfOKQI9tezjyMieNQJmkm2wUim+yFSXpO4IRT4+pJP3N8ZS5HNU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rcvHrAOq; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A45EC2BD10; Fri, 14 Jun 2024 12:33:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718368419; bh=GLgMoYqQYcCbuXGoGXD8j9JN7q1v3yKblwBp8qWBNDg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=rcvHrAOqi7cmNK2hFeCL7mbpMGmgqrkr6N49QVPhLOWr5S8WjJFX0GYBoPBV7trxu ZRB+kKsmsKVpgZ7ZVgACEy4v7DwvXhTnNrQpv0hIuM+v/+dvM/xVzIMEZ3kNHzJ7mR R3ZcuDSWDGVvCK2+iAwsF1BNEtdYTuJV7uqSVtfHvu+4x97PDKoPsHkq9kuqycwzVx SbYBqbpFZA4IUdxaKRBi7ukGp0Tr65TZhdZk/fl8ZrUASGKm0rBS4QFLgaDdW5F37B au5NprFajJ/GHL6J7ArBL1doaJfhrQEPKSKs4VBA9HGJU8SXZURILQtPHDlwaBRBjn VkzcRoq0YscPQ== 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 1sI67d-003upH-Cb; Fri, 14 Jun 2024 13:33:37 +0100 Date: Fri, 14 Jun 2024 13:33:37 +0100 Message-ID: <86sexfk8ke.wl-maz@kernel.org> From: Marc Zyngier To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, mark.rutland@arm.com, Mark Brown , James Clark , Rob Herring , Suzuki Poulose , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , linux-perf-users@vger.kernel.org, Oliver Upton , James Morse , kvmarm@lists.linux.dev Subject: Re: [PATCH V18 2/9] KVM: arm64: Explicitly handle BRBE traps as UNDEFINED In-Reply-To: <20240613061731.3109448-3-anshuman.khandual@arm.com> References: <20240613061731.3109448-1-anshuman.khandual@arm.com> <20240613061731.3109448-3-anshuman.khandual@arm.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.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, mark.rutland@arm.com, broonie@kernel.org, james.clark@arm.com, robh@kernel.org, suzuki.poulose@arm.com, peterz@infradead.org, mingo@redhat.com, acme@kernel.org, linux-perf-users@vger.kernel.org, oliver.upton@linux.dev, james.morse@arm.com, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 13 Jun 2024 07:17:24 +0100, Anshuman Khandual wrote: > > The Branch Record Buffer Extension (BRBE) adds a number of system registers > and instructions, which we don't currently intend to expose to guests. Our > existing logic handles this safely, but this could be improved with some > explicit handling of BRBE. > > The presence of BRBE is currently hidden from guests as the cpufeature > code's ftr_id_aa64dfr0[] table doesn't have an entry for the BRBE field, > and so this will be zero in the sanitised value of ID_AA64DFR0 exposed to > guests via read_sanitised_id_aa64dfr0_el1(). As the ftr_id_aa64dfr0[] table > may gain an entry for the BRBE field in future, for robustness we should > explicitly mask out the BRBE field in read_sanitised_id_aa64dfr0_el1(). > > The BRBE system registers and instructions are currently trapped by the > existing configuration of the fine-grained traps. As neither the registers > nor the instructions are described in the sys_reg_descs[] table, > emulate_sys_reg() will warn that these are unknown before injecting an > UNDEFINED exception into the guest. > > Well-behaved guests shouldn't try to use the registers or instructions, but > badly-behaved guests could use these, resulting in unnecessary warnings. To > avoid those warnings, we should explicitly handle the BRBE registers and > instructions as UNDEFINED. > > Address the above by having read_sanitised_id_aa64dfr0_el1() mask out the > ID_AA64DFR0.BRBE field, and explicitly handling all of the BRBE system > registers and instructions as UNDEFINED. > > Cc: Marc Zyngier > Cc: Oliver Upton > Cc: James Morse > Cc: Suzuki K Poulose > Cc: Catalin Marinas > Cc: Will Deacon > Cc: kvmarm@lists.linux.dev > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Anshuman Khandual > ---- > Changes in V18: > > - Updated the commit message > > arch/arm64/kvm/sys_regs.c | 56 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 56 insertions(+) > Reviewed-by: Mark Rutland > --- > arch/arm64/kvm/sys_regs.c | 56 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 56 insertions(+) > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 22b45a15d068..3d4686abe5ee 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1304,6 +1304,11 @@ static int set_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r, > return 0; > } > > +#define BRB_INF_SRC_TGT_EL1(n) \ > + { SYS_DESC(SYS_BRBINF_EL1(n)), undef_access }, \ > + { SYS_DESC(SYS_BRBSRC_EL1(n)), undef_access }, \ > + { SYS_DESC(SYS_BRBTGT_EL1(n)), undef_access } \ > + > /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */ > #define DBG_BCR_BVR_WCR_WVR_EL1(n) \ > { SYS_DESC(SYS_DBGBVRn_EL1(n)), \ > @@ -1722,6 +1727,9 @@ static u64 read_sanitised_id_aa64dfr0_el1(struct kvm_vcpu *vcpu, > /* Hide SPE from guests */ > val &= ~ID_AA64DFR0_EL1_PMSVer_MASK; > > + /* Hide BRBE from guests */ > + val &= ~ID_AA64DFR0_EL1_BRBE_MASK; > + > return val; > } > > @@ -2240,6 +2248,52 @@ static const struct sys_reg_desc sys_reg_descs[] = { > { SYS_DESC(SYS_DBGCLAIMCLR_EL1), trap_raz_wi }, > { SYS_DESC(SYS_DBGAUTHSTATUS_EL1), trap_dbgauthstatus_el1 }, > > + /* > + * BRBE branch record sysreg address space is interleaved between > + * corresponding BRBINF_EL1, BRBSRC_EL1, and BRBTGT_EL1. > + */ > + BRB_INF_SRC_TGT_EL1(0), > + BRB_INF_SRC_TGT_EL1(16), > + BRB_INF_SRC_TGT_EL1(1), > + BRB_INF_SRC_TGT_EL1(17), > + BRB_INF_SRC_TGT_EL1(2), > + BRB_INF_SRC_TGT_EL1(18), > + BRB_INF_SRC_TGT_EL1(3), > + BRB_INF_SRC_TGT_EL1(19), > + BRB_INF_SRC_TGT_EL1(4), > + BRB_INF_SRC_TGT_EL1(20), > + BRB_INF_SRC_TGT_EL1(5), > + BRB_INF_SRC_TGT_EL1(21), > + BRB_INF_SRC_TGT_EL1(6), > + BRB_INF_SRC_TGT_EL1(22), > + BRB_INF_SRC_TGT_EL1(7), > + BRB_INF_SRC_TGT_EL1(23), > + BRB_INF_SRC_TGT_EL1(8), > + BRB_INF_SRC_TGT_EL1(24), > + BRB_INF_SRC_TGT_EL1(9), > + BRB_INF_SRC_TGT_EL1(25), > + BRB_INF_SRC_TGT_EL1(10), > + BRB_INF_SRC_TGT_EL1(26), > + BRB_INF_SRC_TGT_EL1(11), > + BRB_INF_SRC_TGT_EL1(27), > + BRB_INF_SRC_TGT_EL1(12), > + BRB_INF_SRC_TGT_EL1(28), > + BRB_INF_SRC_TGT_EL1(13), > + BRB_INF_SRC_TGT_EL1(29), > + BRB_INF_SRC_TGT_EL1(14), > + BRB_INF_SRC_TGT_EL1(30), > + BRB_INF_SRC_TGT_EL1(15), > + BRB_INF_SRC_TGT_EL1(31), > + > + /* Remaining BRBE sysreg addresses space */ > + { SYS_DESC(SYS_BRBCR_EL1), undef_access }, > + { SYS_DESC(SYS_BRBFCR_EL1), undef_access }, > + { SYS_DESC(SYS_BRBTS_EL1), undef_access }, > + { SYS_DESC(SYS_BRBINFINJ_EL1), undef_access }, > + { SYS_DESC(SYS_BRBSRCINJ_EL1), undef_access }, > + { SYS_DESC(SYS_BRBTGTINJ_EL1), undef_access }, > + { SYS_DESC(SYS_BRBIDR0_EL1), undef_access }, > + > { SYS_DESC(SYS_MDCCSR_EL0), trap_raz_wi }, > { SYS_DESC(SYS_DBGDTR_EL0), trap_raz_wi }, > // DBGDTR[TR]X_EL0 share the same encoding > @@ -2751,6 +2805,8 @@ static struct sys_reg_desc sys_insn_descs[] = { > { SYS_DESC(SYS_DC_CISW), access_dcsw }, > { SYS_DESC(SYS_DC_CIGSW), access_dcgsw }, > { SYS_DESC(SYS_DC_CIGDSW), access_dcgsw }, > + { SYS_DESC(OP_BRB_IALL), undef_access }, > + { SYS_DESC(OP_BRB_INJ), undef_access }, > }; > > static const struct sys_reg_desc *first_idreg; I don't think we need any update to the sys_reg table to handle this. Instead, we should make use of the FGU infrastructure that has been in since 6.9 to make this stuff UNDEF unconditionally. It should be as simple as: diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index ee33f5467ce5..7cafe3f72c01 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -4964,6 +4964,11 @@ void kvm_init_sysreg(struct kvm_vcpu *vcpu) kvm->arch.fgu[HAFGRTR_GROUP] |= ~(HAFGRTR_EL2_RES0 | HAFGRTR_EL2_RES1); + if (!kvm_has_feat(kvm, ID_AA64DFR0_EL1, BRBE, IMP)) + kvm->arch.fgu[HDFGRTR_GROUP] |= (HDFGRTR_nBRBDATA | + HDFGRTR_nBRBCTL | + HDFGRTR_nBRBIDR); + set_bit(KVM_ARCH_FLAG_FGU_INITIALIZED, &kvm->arch.flags); out: mutex_unlock(&kvm->arch.config_lock); which is of course untested, but that I expect to be correct. Thanks, M. -- Without deviation from the norm, progress is not possible.