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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82BC8C433B4 for ; Fri, 9 Apr 2021 08:30:42 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0AC1061105 for ; Fri, 9 Apr 2021 08:30:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0AC1061105 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; 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=7GDGz91mHFHCihj9fLSai9zMGfeSTXZz8JtL7RscKgU=; b=ge4kp7RxYzqqPwSDwEhFjov6X 1ucgOy78l8S5/unzIwXUq8UaMkox8sR1Nmdzp5sj6w/lpYOwwq6x56yrWgsulHdtLE8sJMFX4V534 0CkHTxq+coQIeRpV8ofgxM45+da1LnYWq9owxQsydQyjYnjsoaj0iPyEsik5252FqJQOH9BI6M1yQ V+xCwuWfIRPoqUrPC7O3lGNoyvk17wStfa0SIKLObPRTtHbbwtXEd+ZgS8lahaWcaJ/8ft9TS+AmN MOa/bM0s9EaEGLiq3ldDXVhqK1bU0WZXvT5cPn9xSeylB/kxfC/nByJ/P4wjaAeEZJgLXk6dd161V L4hMTZJvw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lUmVp-0003AD-1X; Fri, 09 Apr 2021 08:29:09 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lUmVj-00038r-Ar for linux-arm-kernel@lists.infradead.org; Fri, 09 Apr 2021 08:29:05 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BF8BF61185; Fri, 9 Apr 2021 08:29:01 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lUmVf-006UCP-Jd; Fri, 09 Apr 2021 09:28:59 +0100 Date: Fri, 09 Apr 2021 09:28:58 +0100 Message-ID: <87mtu7oo8l.wl-maz@kernel.org> From: Marc Zyngier To: Arnd Bergmann Cc: Linux ARM , Hector Martin , Mark Rutland , Will Deacon , Catalin Marinas , Android Kernel Team Subject: Re: [PATCH v3 3/3] arm64: Get rid of CONFIG_ARM64_VHE In-Reply-To: References: <20210408131010.1109027-1-maz@kernel.org> <20210408131010.1109027-4-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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: arnd@kernel.org, linux-arm-kernel@lists.infradead.org, marcan@marcan.st, mark.rutland@arm.com, will@kernel.org, catalin.marinas@arm.com, kernel-team@android.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-20210409_092903_778532_F7F27D25 X-CRM114-Status: GOOD ( 36.34 ) 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 Thu, 08 Apr 2021 22:47:38 +0100, Arnd Bergmann wrote: > > On Thu, Apr 8, 2021 at 3:10 PM Marc Zyngier wrote: > > > > CONFIG_ARM64_VHE was introduced with ARMv8.1 (some 7 years ago), > > and has been enabled by default for almost all that time. > > > > Given that newer systems that are VHE capable are finally becoming > > available, and that some systems are even incapable of not running VHE, > > drop the configuration altogether. > > > > Anyone willing to stick to non-VHE on VHE hardware for obscure > > reasons should use the 'kvm-arm.mode=nvhe' command-line option. > > Have you considered adding options to do the reverse logic for this > and other features, such as making support for the old non-VHE > optional at compile time? This nVHE code is exclusively limited to KVM, because the whole point of VHE is that the EL1 kernel can run at EL2 completely unchanged. Furthermore, nVHE has properties that VHE cannot deliver, such as memory isolation between host and guests. So no, I wouldn't consider make it optional at compile time. Instead, I would consider jettisoning the nVHE EL2 code after init to save a handful of pages when running on a VHE-capable system in VHE mode. > > I understand that so far the rule is (almost) always that an arm64 kernel > should run on any Armv8.0-A or higher system regardless of configuration, > but the now announced Armv9.0-A definition might be the chance to > introduce the concept of a minimum level the way we do on other > architectures (e.g. armv6/v6k/v7 or k8/pentium4/core2/atom/generic). > > The way I can see this working would be to have a single user-visible > option that controls whether the kernel supports only Armv9.0-A/Armv8.5-A > and assumes all mandatory features of that are present, or it remains > as before and supports all implementations back to the first v8. The view that v8.5/v9 is a monolithic setup with a set of mandatory option is unfortunately disconnected from reality. Reality is that an implementer picks and chooses whatever feature set they want irrespective of what the architecture says, and the architecture revision is nothing but an index into the documentation. Features that were mandatory often become optional, and/or are further made unimplementable due to some other extension of the architecture. We also have the extremely common case where a feature that is usable on a host isn't virtualisable, meaning that the kernel gets exposed different feature sets depending on whether it runs bare-metal or not, which puts another nail on the "per-revision feature set" coffin. The ARM architecture is effectively a mix-and-match system, where you choose the feature set you want for a single vertically integrated application, and not a nice linear progression of features that land in bulk. > This would help eliminate the runtime detection for not just VHE but > also LSE, LPA, PAN, etc. Not sure how significant the cost of any of > those are in terms of runtime performance and/or code size, but it > would feel nice to be able to build a kernel that can actually rely > on sane hardware features even if it will take a few more years before > that hardware becomes common enough to actually get some distros > ship a kernel that requires v8.5/v9.0. We went there with 32bit because we were forced to: different ISAs, different page table formats. I would rather keep a single kernel until we get to that point of divergence *or* that we can demonstrate such a significant performance/maintenance improvement that it'd be silly not to do it. The published architecture does not hint at such changes yet, nor has performance overhead been reported due to "feature bloat". The current feature discovery and runtime patching seems adequate and saves us from the bitrot effect that multiple configurations inevitably would trigger. So at the moment, I am strongly in favor of keeping the current "single kernel" approach, and even drop more of the existing configuration symbols (though some have ugly toolchain constraints). 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