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 3D15CC27C6E for ; Mon, 17 Jun 2024 07:41:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VQUsvS4eml5Z+NWMNKtcCPIMlpEDGjLLELD4MaN0E5o=; b=zc/QUZAO6M4yg/K2bm40OzY90J s9EuQ0Kz3G8z0ZCC+1fUWrEQx+rcxWh9rK0NL8zYwvoTPx3VkFJWicl7JGyaNOOdpIIok8vbDWzUX pev5etrtulrxl210K6S8X09lxGJeovvn0lwckSLgMCgZ3C/447t2s+kTzwjLdM/ukyfc4yhI+n3r1 MPJm1mLClR43Si0naIYCnk/8KcUzFThONpu7/3pxb2QRx8kEdp4dd7nRVSgSuohxV+JFWtjJKbXjl isMfArlH9iY1/luLlefz087cYA/X8CU+gUCsTFPeb38N97KpqXvSt8Tj8bMr8i+D4moN8+PtvN2kK KvwyPTTw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJ6zN-00000009how-3xRO; Mon, 17 Jun 2024 07:41:17 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sJ6zJ-00000009hm0-0dX0 for linux-arm-kernel@lists.infradead.org; Mon, 17 Jun 2024 07:41:15 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id A2FEECE0FC4; Mon, 17 Jun 2024 07:41:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6A7EC2BD10; Mon, 17 Jun 2024 07:41:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718610069; bh=6fjH5+2JhBPufwYdBrMxQDSsZf/nxe3KJGcBk5Ezhkc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=nsv0LF/GFpgY/pRBcbkxLmyR1g1fwMIdIGJaLsL2g8c+CfHSj69vnY4zknfKNxe3l U14QXZsflSOVucEVMbM4yftigMouJHfSxgqjPplx9g2E28FvTn79fU3AEPRwmvExm+ ArEzC08FlVwZcNkgEdO6YVkOzdLT1jbZE/Z/mW1lGL6CdjPnd/G4V0cqFpaXMAt+gt xCSGbV0Q0iwaaLuEjv/nxT4f2Wj6/az/JFG4vdbuj2+IvOCHRyO5Z8rIvKDcjsDMXr kK1CpArdycQRz1yDT8H47XiWhT0fPbhTzCopNinn1VBwfkaqMH8G0KBw5uW/XHG1ky NYQLWsVFROEhQ== 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 1sJ6zD-004VaC-4P; Mon, 17 Jun 2024 08:41:07 +0100 Date: Mon, 17 Jun 2024 08:41:06 +0100 Message-ID: <86jzioj9t9.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: References: <20240613061731.3109448-1-anshuman.khandual@arm.com> <20240613061731.3109448-3-anshuman.khandual@arm.com> <86sexfk8ke.wl-maz@kernel.org> <86r0czk6wd.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.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=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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240617_004114_785897_A1F3D3EB X-CRM114-Status: GOOD ( 27.82 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 17 Jun 2024 07:27:13 +0100, Anshuman Khandual wrote: > On 6/14/24 18:39, Marc Zyngier wrote: > > On Fri, 14 Jun 2024 13:33:37 +0100, > > > > Actually, to disable the *instructions*, a similar hack must be > > applied to HFGITR_EL2. The resulting patch should be something like: > > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index ee33f5467ce5..49d86dae8d80 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -4964,6 +4964,15 @@ 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); Obviously, this needs to be spelled HDFGRTR_EL2_nBRB* so that it actually compiles. > > + kvm->arch.fgu[HFGITR_GROUP] |= (HFGITR_EL2_nBRBINJ | > > + HFGITR_EL2_nBRBIALL); > > + } > > + > > + > > set_bit(KVM_ARCH_FLAG_FGU_INITIALIZED, &kvm->arch.flags); > > out: > > mutex_unlock(&kvm->arch.config_lock); > > This makes sense, will remove all the changes to sys_reg table and > instead fold the above suggestion into the patch. > > > > > The implicit dependency here is that FGT is always present on a system > > that implements BRBE. The architecture supports this assertion: > > > > - BRBE is not available before ARMv9.1 > > - FGT is mandatory from ARMv8.6 > > > > Given that v9.1 is congruent to v8.6, we have the required overlap. > > So this overlap need not be asserted in software again ? I don't think there's a need for that. We went through the same thing with SME (which has the exact same dependency), and concluded that there was no need to paper over broken implementations at the moment (only QEMU was affected, and that was quickly fixed). If we find an implementation in the wild that didn't get the memo, we can add a workaround at that time. M. -- Without deviation from the norm, progress is not possible.