From patchwork Wed May 1 16:34:00 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Will Deacon X-Patchwork-Id: 13651019 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 742ECC4345F for ; Wed, 1 May 2024 16:34:22 +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: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wyHDyCHGvLUkZEXUUhSzavJTRdGNKzWAJoAfm346lmg=; b=S5FpdLEVoawglH Lqme8foU/IzyyuaXfTDEqBCLR5gXDlUGDh7iGU1hXhoKM7eHTspV83YVtQv2Nlpo6UX49DoeFnxl6 Yol3Q4pYvCCYHz8AL3RxzgzRMerpF9XUc/L2FTxj+ATNYDMolIsmcX8NO8ACTY1G1j/mgjuMCSgFZ tJXTBj2+Jiq5t1vOXCudg9MxFoq8z38tfWMn4+GqyQeFT2MZMd/RVZiO+BZibcMyK4Na7LNh3DRZP +1SAnNHp7p1ldgWUCXsXHgQkRagsi27wBDugBGG4/9whVnMhvW/B+QW1cBxjzc25Bf1b0YuSCn9QO 7BDSYuAZ69ecAGU7Q4Tg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s2CuL-0000000AASQ-2sWV; Wed, 01 May 2024 16:34:13 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s2CuH-0000000AAQM-3In7 for linux-arm-kernel@lists.infradead.org; Wed, 01 May 2024 16:34:11 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id DAF1B61122; Wed, 1 May 2024 16:34:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61DB2C4AF1A; Wed, 1 May 2024 16:34:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1714581248; bh=zqLa/sCvSK7SMwwaQAzL9RSCgjQ1JYfXXSvbUh4TT1M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rtPlmTfCHmmCqqWA4SFP+Ks+x731jXj79jyWKNF1nAdMT/yeOP8EcztGJVXagdPLE WHIg+hy1JxZobuYubFw/RAVdFFrAhOEkhz6jhbBUSJR3PB13VWrehoBgSwatiHS2U3 CWZhlAIoH8B2hjllEnbmMIY+v/5/9nRM6izCm1n7B83SE66BU+OzmEQvnQ8Q2W5ETy U2n26nwJymoZEL0HyQHyLtg4lhhBjOSScPjS6G+9JmftlhfLcUHnv2Drta4IhzFFiY NYtDHfKls2lSGVHSlZP6lN//Alc9XMTWkJ3cq4ka/H5YYfrhmk+TCojVpc+UMZriIf 3cRyFgGSIj6Wg== From: Will Deacon To: kvmarm@lists.linux.dev Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , Marc Zyngier , Oliver Upton Subject: [PATCH 2/2] KVM: arm64: Use hVHE in pKVM by default on CPUs with VHE support Date: Wed, 1 May 2024 17:34:00 +0100 Message-Id: <20240501163400.15838-3-will@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20240501163400.15838-1-will@kernel.org> References: <20240501163400.15838-1-will@kernel.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240501_093409_977352_F9D60F69 X-CRM114-Status: GOOD ( 14.36 ) 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 The early command line parsing treats "kvm-arm.mode=protected" as an alias for "id_aa64mmfr1.vh=0", forcing the use of nVHE so that the host kernel runs at EL1 with the pKVM hypervisor at EL2. With the introduction of hVHE support in ad744e8cb346 ("arm64: Allow arm64_sw.hvhe on command line"), the hypervisor can run using the EL2+0 translation regime. This is interesting for unusual CPUs that have VH stuck to 1, but also because it opens the possibility of a hypervisor "userspace" in the distant future which could be used to isolate vCPU contexts in the hypervisor (see Marc's talk from KVM Forum 2022 [1]). Repaint the "kvm-arm.mode=protected" alias to map to "arm64_sw.hvhe=1", which will use hVHE on CPUs that support it and remain with nVHE otherwise. [1] https://www.youtube.com/watch?v=1F_Mf2j9eIo Signed-off-by: Will Deacon Acked-by: Oliver Upton --- arch/arm64/kernel/pi/idreg-override.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/pi/idreg-override.c b/arch/arm64/kernel/pi/idreg-override.c index 39c9253fcf23..c20549e43a77 100644 --- a/arch/arm64/kernel/pi/idreg-override.c +++ b/arch/arm64/kernel/pi/idreg-override.c @@ -210,7 +210,7 @@ static const struct { char feature[FTR_ALIAS_OPTION_LEN]; } aliases[] __initconst = { { "kvm_arm.mode=nvhe", "arm64_sw.hvhe=0 id_aa64mmfr1.vh=0" }, - { "kvm_arm.mode=protected", "id_aa64mmfr1.vh=0" }, + { "kvm_arm.mode=protected", "arm64_sw.hvhe=1" }, { "arm64.nosve", "id_aa64pfr0.sve=0" }, { "arm64.nosme", "id_aa64pfr1.sme=0" }, { "arm64.nobti", "id_aa64pfr1.bt=0" },