From mboxrd@z Thu Jan 1 00:00:00 1970 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 20465134B2 for ; Mon, 23 Oct 2023 09:35:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PxTeNYTS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E20BC433C7; Mon, 23 Oct 2023 09:35:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698053705; bh=OpjH4CLB0Ep8F60JOdq9CgTyteadUsPPUdB5cviLW94=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=PxTeNYTS6/8B0uYP1YmOkhBqzzMRgjbiE77w5DQRCsFhGAVLLNYNUzPjcM8hoQ8GC 9CNxYVIh+8gkVWS36F9dLWldGxoUV5K8GdiQMT9OSFm6bd2qK7bj8sjiYwZyduUWih avJU3026iHvaQTYwIXF5albqFnLOLn76YYEuJqZQN9nWYLg05vkkg2NHQtJ58QLAtn v/eU62yB2zG7+UoWB+J0Pk5xfYlOB9WDlSUtB7Dg2yFRk+FVr75F5vaXG1qe72V9wR X27P54T5XSvGiem4TLPigO4b6GE4yZv5DLfO3LtjFjT5nrkf7CY88KumPFulAx6E70 eFJRnlio58D3w== 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 1qurKx-006myf-5D; Mon, 23 Oct 2023 10:35:03 +0100 Date: Mon, 23 Oct 2023 10:34:58 +0100 Message-ID: <867cnd65rx.wl-maz@kernel.org> From: Marc Zyngier To: Ryan Roberts Cc: Catalin Marinas , Will Deacon , Oliver Upton , Suzuki K Poulose , James Morse , Zenghui Yu , Ard Biesheuvel , Anshuman Khandual , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v4 04/12] KVM: arm64: Add ARM64_HAS_LPA2 CPU capability In-Reply-To: References: <20231009185008.3803879-1-ryan.roberts@arm.com> <20231009185008.3803879-5-ryan.roberts@arm.com> <86cyx9n1yp.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.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev 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: ryan.roberts@arm.com, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, suzuki.poulose@arm.com, james.morse@arm.com, yuzenghui@huawei.com, ardb@kernel.org, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, 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 Fri, 20 Oct 2023 16:03:37 +0100, Ryan Roberts wrote: > > On 20/10/2023 09:16, Marc Zyngier wrote: > > On Mon, 09 Oct 2023 19:50:00 +0100, > > Ryan Roberts wrote: > >> > >> +static bool has_lpa2(const struct arm64_cpu_capabilities *entry, int scope) > >> +{ > >> + u64 mmfr0; > >> + bool ret; > >> + > >> + mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1); > >> + ret = has_lpa2_at_stage1(mmfr0); > >> + > >> + if (kvm_get_mode() != KVM_MODE_NONE) > >> + ret = ret && has_lpa2_at_stage2(mmfr0); > > > > Isn't it too late to go back on the decision to use LPA2 at S1 if you > > realise that S2 doesn't support it? > > The KVM mode dependent part was a change that Oliver asked for. I guess you are > talking about kernel S1? I don't think it's too late here to decide whether the > (nvhe) hyp s1 should use LPA2. But I guess your point is that kernel s1 would > have had to decide much earlier in boot and will have had to take LPA2 support > in both S1 and S2 into account, and would not have the KVM mode info available > to it at that point? That's roughly my point. When we reach this point on a VHE system, we're pretty far along and I'm not sure we can turn back. In all honesty, if a system doesn't support LPA2 at S2, it is in a pretty bad shape and we shouldn't bother supporting it. Or at least not with KVM. Just because the architecture allows braindead configurations doesn't mean we have to go out of our way to support them. In this case, I'd be absolutely fine with disabling KVM altogether. > > Why isn't this patch the first or second in the series? You could use > > it to drive the LPA2 decision in the patch #2, avoiding the ugly lpa2 > > flag... > > I still only think this works if we put my patch and Ard's patch in atomically? > Or at least force has_lpa2() to always return false until both are in, then flip > the switch atomically. Whichever works for you. My only ask is to try to minimise the churn here. Thanks, M. -- Without deviation from the norm, progress is not possible. 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 9B90EC001E0 for ; Mon, 23 Oct 2023 09:35:38 +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=9EKFnvMXMVK9UmcEFQJHrAbUGwp113EVevNg6JeSiYs=; b=0KFZawJpL2TqX9 AFbmSYG3rk2cvxI8+HNWHGGPwdev+4xagtDOSjGwvT9RCPdB04Cvxt7433oLVhYfSanLquHVJtG9v jjDM5Vxk77TggJrZi/ZlZgu80oIZseeqN36805meiNIq3If2/LMLEzFfVVdHGvJSy58dbVLPuq9/5 3oppX1nv0u6CVLlGcEBW2Zr2dN7/KTPsjus0bZsGqG3a123pfbJJ96ZgIF0+u/2zWsL/YXS7Xt385 TagF2m3/7b5iJU8yfaPuCnKLodflqz+lOvy9TlDrAE7NT9autfKeiEn2x2pByb8pkYq97d6t9Yj5T O8VBU2pM/gn/Ijfs2cgA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qurL5-006tZz-0r; Mon, 23 Oct 2023 09:35:11 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qurL2-006tY8-12 for linux-arm-kernel@lists.infradead.org; Mon, 23 Oct 2023 09:35:09 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 44A1DB818C0; Mon, 23 Oct 2023 09:35:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E20BC433C7; Mon, 23 Oct 2023 09:35:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1698053705; bh=OpjH4CLB0Ep8F60JOdq9CgTyteadUsPPUdB5cviLW94=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=PxTeNYTS6/8B0uYP1YmOkhBqzzMRgjbiE77w5DQRCsFhGAVLLNYNUzPjcM8hoQ8GC 9CNxYVIh+8gkVWS36F9dLWldGxoUV5K8GdiQMT9OSFm6bd2qK7bj8sjiYwZyduUWih avJU3026iHvaQTYwIXF5albqFnLOLn76YYEuJqZQN9nWYLg05vkkg2NHQtJ58QLAtn v/eU62yB2zG7+UoWB+J0Pk5xfYlOB9WDlSUtB7Dg2yFRk+FVr75F5vaXG1qe72V9wR X27P54T5XSvGiem4TLPigO4b6GE4yZv5DLfO3LtjFjT5nrkf7CY88KumPFulAx6E70 eFJRnlio58D3w== 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 1qurKx-006myf-5D; Mon, 23 Oct 2023 10:35:03 +0100 Date: Mon, 23 Oct 2023 10:34:58 +0100 Message-ID: <867cnd65rx.wl-maz@kernel.org> From: Marc Zyngier To: Ryan Roberts Cc: Catalin Marinas , Will Deacon , Oliver Upton , Suzuki K Poulose , James Morse , Zenghui Yu , Ard Biesheuvel , Anshuman Khandual , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH v4 04/12] KVM: arm64: Add ARM64_HAS_LPA2 CPU capability In-Reply-To: References: <20231009185008.3803879-1-ryan.roberts@arm.com> <20231009185008.3803879-5-ryan.roberts@arm.com> <86cyx9n1yp.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.1 (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: ryan.roberts@arm.com, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, suzuki.poulose@arm.com, james.morse@arm.com, yuzenghui@huawei.com, ardb@kernel.org, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, 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-20231023_023508_679871_39D97C6A X-CRM114-Status: GOOD ( 28.96 ) 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 On Fri, 20 Oct 2023 16:03:37 +0100, Ryan Roberts wrote: > > On 20/10/2023 09:16, Marc Zyngier wrote: > > On Mon, 09 Oct 2023 19:50:00 +0100, > > Ryan Roberts wrote: > >> > >> +static bool has_lpa2(const struct arm64_cpu_capabilities *entry, int scope) > >> +{ > >> + u64 mmfr0; > >> + bool ret; > >> + > >> + mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1); > >> + ret = has_lpa2_at_stage1(mmfr0); > >> + > >> + if (kvm_get_mode() != KVM_MODE_NONE) > >> + ret = ret && has_lpa2_at_stage2(mmfr0); > > > > Isn't it too late to go back on the decision to use LPA2 at S1 if you > > realise that S2 doesn't support it? > > The KVM mode dependent part was a change that Oliver asked for. I guess you are > talking about kernel S1? I don't think it's too late here to decide whether the > (nvhe) hyp s1 should use LPA2. But I guess your point is that kernel s1 would > have had to decide much earlier in boot and will have had to take LPA2 support > in both S1 and S2 into account, and would not have the KVM mode info available > to it at that point? That's roughly my point. When we reach this point on a VHE system, we're pretty far along and I'm not sure we can turn back. In all honesty, if a system doesn't support LPA2 at S2, it is in a pretty bad shape and we shouldn't bother supporting it. Or at least not with KVM. Just because the architecture allows braindead configurations doesn't mean we have to go out of our way to support them. In this case, I'd be absolutely fine with disabling KVM altogether. > > Why isn't this patch the first or second in the series? You could use > > it to drive the LPA2 decision in the patch #2, avoiding the ugly lpa2 > > flag... > > I still only think this works if we put my patch and Ard's patch in atomically? > Or at least force has_lpa2() to always return false until both are in, then flip > the switch atomically. Whichever works for you. My only ask is to try to minimise the churn here. Thanks, 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