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 6BDC4C636CC for ; Tue, 31 Jan 2023 20:45:09 +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=ShRV8FZUnPV/cd3ZZNwiyS1QkZvn/2TsrXFMbhlZ4M0=; b=B7SGBi0yM3q4KJ 5M2CShZQy3u216WLuVPOndl+rpkBUa0YLQyEJruhX7f05vNxbJkPPKPPx9Y8bAaXE4M8GWPZ18CVM +IpPMa4zKnhK8FkSfRMA7BE8J684nXygoJ0bMjfipJmYQiZL3HYuRA7NeCP9SqLuGh2NDYxTGVa/0 ok6Hey6uXwwx69PCgku1MbrojbAzGVNJhk0EpaiM4G1rzLDeGMsVg7MONYJjbTDaM+YkYDv0FL0EC jX+A5qyzTSW39z3OJ28cZphpYJo2usUbtu3bZk/CgERRHe84B4YOz4dWPReDO/jMrcjdl+DgGINr0 HbtJHC6QHyJ8LYIDq3IQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMxUA-009IHC-K4; Tue, 31 Jan 2023 20:44:10 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMxU7-009IGj-I4 for linux-arm-kernel@lists.infradead.org; Tue, 31 Jan 2023 20:44:09 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F07E4610F4; Tue, 31 Jan 2023 20:44:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 62133C433EF; Tue, 31 Jan 2023 20:44:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675197846; bh=4UWfK8mNB1q8988fZ//H/K5RBanIYHQbvHPtQD0hyUQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RkzNAdihiJ6SZP3szxsTNKZWOPCiRsByYf9NPLPBxG+uP2aBHwXfWzVI9KVtwWLCv LoXhPVxkSyNUi/SbujsYBak5zct43Ho7tb67fD+bw+3UVB3OeqSq8476LHR3JSw4hi qVdzMvQTrbRmxUX9Lca/yHmiAX6wAcEjooCVHMn3xGKC4sf4mwa9GNaGS8JhYsKI/l ogjO1MKc1dPzG/meSF184QP50Aj1zFs2HsDWUkb5dQqI0F6+ymJlVeEZFfD0U8W+oX hUEKuZQxavMgpA9/rk7r0LpGZ3lvOYyJvnshKDNu+RmQvol4dKNeuIuXebtvjAojNR 2BR+hqm1PFvMQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.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 1pMxU3-006JkE-U7; Tue, 31 Jan 2023 20:44:04 +0000 Date: Tue, 31 Jan 2023 20:44:03 +0000 Message-ID: <87357qe8oc.wl-maz@kernel.org> From: Marc Zyngier To: Suzuki K Poulose Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Alexandru Elisei , Andre Przywara , Chase Conklin , Christoffer Dall , Ganapatrao Kulkarni , Jintack Lim , Russell King , James Morse , Oliver Upton , Zenghui Yu Subject: Re: [PATCH v8 01/69] arm64: Add ARM64_HAS_NESTED_VIRT cpufeature In-Reply-To: <3c15760c-c76f-3d5d-a661-442459ce4e07@arm.com> References: <20230131092504.2880505-1-maz@kernel.org> <20230131092504.2880505-2-maz@kernel.org> <86cz6u248j.wl-maz@kernel.org> <3c15760c-c76f-3d5d-a661-442459ce4e07@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/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: 185.219.108.64 X-SA-Exim-Rcpt-To: suzuki.poulose@arm.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, alexandru.elisei@arm.com, andre.przywara@arm.com, chase.conklin@arm.com, christoffer.dall@arm.com, gankulkarni@os.amperecomputing.com, jintack@cs.columbia.edu, rmk+kernel@armlinux.org.uk, james.morse@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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230131_124407_698696_E1C2DAC1 X-CRM114-Status: GOOD ( 38.77 ) 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 Tue, 31 Jan 2023 17:34:39 +0000, Suzuki K Poulose wrote: > > Hi Marc, > > On 31/01/2023 14:00, Marc Zyngier wrote: > > Hi Suzuki, > > > > On Tue, 31 Jan 2023 13:47:31 +0000, > > Suzuki K Poulose wrote: > >> > >> Hi Marc > >> > >> On 31/01/2023 09:23, Marc Zyngier wrote: > >>> From: Jintack Lim > >>> > >>> Add a new ARM64_HAS_NESTED_VIRT feature to indicate that the > >>> CPU has the ARMv8.3 nested virtualization capability, together > >>> with the 'kvm-arm.mode=nested' command line option. > >>> > >>> This will be used to support nested virtualization in KVM. > >>> > >>> Reviewed-by: Russell King (Oracle) > >>> Signed-off-by: Jintack Lim > >>> Signed-off-by: Andre Przywara > >>> Signed-off-by: Christoffer Dall > >>> [maz: moved the command-line option to kvm-arm.mode] > >> > >> Should this be separate kvm-arm mode ? Or can this be tied to > >> is_kernel_in_hyp_mode() ? Given this mode (from my limited > >> review) doesn't conflict with normal VHE mode (and RME support), > >> adding this explicit mode could confuse the user. > > > > What is exactly the objection here? NV is more or less a VHE++ mode, > > but is also completely experimental and incomplete. > > I am all in for making this an "optional", only enabled it when "I know > what I want". > > kvm-arm.mode=nv kind of seems that the KVM driver is conditioned > mainly for running NV (comparing with the other existing options > for kvm-arm.mode). > > In reality, as you confirmed, NV is an *additional* capability > of a VHE hypervisor. So it would be good to "opt" in for "nv" capability > support. > > e.g, > > kvm-arm.nv=on > > Thinking more about it, either is fine. We had something like this for a long while, but it gave the bad impression what NV and all the other options were orthogonal. But they aren't, really. NV+nVHE is not a thing (at least, as far as I am concerned), and I'm not even mentioning NV+protected. The same reasoning applies to 'protected'. We don't have kvm-arm.protected=on because it only makes sense with nVHE, so we have kvm-arm.mode=protected which is nVHE + weird stuff, just like NV is VHE + even weirder stuff. > >> In case we need a command line to turn the NV mode on/off, > >> we could always use the id-override and simply leave this out ? > > > > I really want an explicit user buy-in. There is absolutely no way this > > can be enabled by default, the risks are way too high. Just look at > > the x86 story: it took them 10 years to enable NV by default. I don't > > expect to do any better. > > Of course, I am with you on that. I realise that we may not be able > to disable nv by default using idreg-override (i.e., without any kernel > command line option). So we may need something outside of that, like > the option mentioned above. The override would indeed need the user to *add* something to disable NV, and we want the opposite. If we really want to allow support for something like NV + protected (to mention the worse possible case), I'd rather we have something like: kvm-arm.mode=protected,nested which would describe the expected behaviour in a compact way, without adding a ton of extra options. But to be honest, I'm not expecting to support any of that within the foreseeable future! 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