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 58F511DFD5; Mon, 27 Nov 2023 13:57:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZtvCY+Vs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F483C43391; Mon, 27 Nov 2023 13:57:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701093463; bh=oSpMQ5218dyTEWrc5+lrGU3fmFrtzbNLW0/HpJXSVJw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZtvCY+VsD0mxPedsnCAUSfIklSH4B6+qrlvz3BPJheWHcycSf76zyZAE35qRAcpMi l3a6SD6tM/XTxN71LNtHA2hIofyXNMF00Oskid0QyVs42bq+Q0bIg9JY2Bs232f322 TQMY1Z4pWiLSzBRkfPjizLAXtFJjx6aPgz5oqkZp/M080mfZN9BfbducOyqY3ScUWm DOd8eUKM6rCHGyF3BMzVTfulwnzzOrvoq8ede8+04M916wGIsva7DG3GZl2yUahtPP 9iG/XdU0rtXiAugV76xkAu1eetiB1+wQh9RrLl1DMZqCZsGTChaxMZf2G3jf3e8lbC LkKgLzbuIm1FA== 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 1r7c7I-00Go0P-Ph; Mon, 27 Nov 2023 13:57:41 +0000 Date: Mon, 27 Nov 2023 13:57:39 +0000 Message-ID: <86cyvvcn8s.wl-maz@kernel.org> From: Marc Zyngier To: Ganapatrao Kulkarni Cc: Miguel Luis , "kvmarm@lists.linux.dev" , "kvm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Alexandru Elisei , Andre Przywara , Chase Conklin , Christoffer Dall , Darren Hart , Jintack Lim , Russell King , James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: Re: [PATCH v11 00/43] KVM: arm64: Nested Virtualization support (FEAT_NV2 only) In-Reply-To: References: <20231120131027.854038-1-maz@kernel.org> <86msv7ylnu.wl-maz@kernel.org> <05733774-4210-4097-9912-fb3aa8542fdd@oracle.com> <86a5r4zafh.wl-maz@kernel.org> <134912e4-beed-4ab6-8ce1-33e69ec382b3@os.amperecomputing.com> <868r6nzc5y.wl-maz@kernel.org> <65dc2a93-0a17-4433-b3a5-430bf516ffe9@os.amperecomputing.com> <86o7fjco13.wl-maz@kernel.org> <86leancjcr.wl-maz@kernel.org> <9f8656c7-8036-4bd6-a0f5-4fa531f95b2f@os.amperecomputing.com> <86jzq3d007.wl-maz@kernel.org> <1fe79744-f8a4-466f-8f1a-32e6fab78be9@os.amperecomputing.com> <86fs0rctcr.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: kvm@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: gankulkarni@os.amperecomputing.com, miguel.luis@oracle.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, darren@os.amperecomputing.com, jintack@cs.columbia.edu, rmk+kernel@armlinux.org.uk, james.morse@arm.com, suzuki.poulose@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 On Mon, 27 Nov 2023 12:18:45 +0000, Ganapatrao Kulkarni wrote: > > >>> I will probably completely disable NV1 support in the next drop, and > >>> make NV support only VHE guests. Which is the only mode that makes any > >>> sense anyway. > >>> > >> > >> Thanks, absolutely makes sense to have *VHE-only* L1, looking forward > >> to a next drop. > > > > Note that this won't be restricted to L1, but will affect *everything. > > > Ok. > > > No non-VHE guest will be supported at any level whatsoever, and NV > > will always expose ID_AA64MMFR4_EL1.E2H0=0b1110, indicating that > > HCR_EL2.NV1 is RES0, on top of ID_AA64MMFR4_EL1.NV_frac=1 (NV2 only). > > OK, Even I was thinking the same instead of the work-around/trick, > then I felt it is still needed since the L1 may be any distro kernel > and it may not have code to interpret/decode ID_AA64MMFR4_EL1.E2H0. The problem is that we can't make that reliable. Current Linux kernels will work with E2H RES1, as you experienced it by hacking KVM. Old crap won't work, but I can't say I care. My point is: KVM NV support will be compliant with the architecture. SW that needs to run with NV will have to understand the version of the architecture that KVM exposes. If you need distros to be upgraded, then you can work with them to update their stuff. M. -- Without deviation from the norm, progress is not possible.