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 C7FEE350280; Mon, 19 Jan 2026 09:39:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768815541; cv=none; b=YcDtS1CJO2UYNn3snhllEGCo5cHKeNbg6Jze2Ie/VOSDp5yiEPVHfgvy3ooNzNFRqFo5kk1j2nlbYoT97Rjs/1U3WdguyITzs/XJfCel6EqwJmXgMj9cWqLxgsbwT9TJ1Z7Ahg97tJDnhASerS3AUpyrON7TetiTQEvRl9EWWBI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768815541; c=relaxed/simple; bh=A1HF+c89D77043i9Z2YC3U06/ILbBibQS8Yb/UCStdI=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=cVCO3NOSQs/q97OwuiEJky/+EOMwHLMV2LCz3h6oMk8MuL4Wc3uCQ2jTH7n6+CqGywWTqCl8iCNH9/QmfxNhgysiDswovpv4bVEBrYxyvq5ge1+7uKOIRzZbm+d7ChALRQsDnSrNaknH9i27qlvXg9l08eVmLGH2M/VIG+Bn3PY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FXmDqQ/x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FXmDqQ/x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DD2AC116C6; Mon, 19 Jan 2026 09:39:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768815541; bh=A1HF+c89D77043i9Z2YC3U06/ILbBibQS8Yb/UCStdI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FXmDqQ/xcE7jFSyt+rW9m8C3jgFKnw1SMkYYkNv26nPYeJEPiAZEzgEvE3Wshrb+b yFVnLJU1YZu23fyZpFrBJII+QHi695VOpIlwjEWoFRNKr/1ywOydjbG64mgWycHaPt c7C9u8h9kP/4S6nV17KqVxK2L1NQmH4tqF+S+QKXSytAuZrnp339Ltmp0tdcXVqKu3 t/KCGkgrlj+XzsB3FGSITAcoRyod4ct2xGf+wtuKFSF7FWj1J38w1of2BprSg7yI65 uz56vhpcyLSvC/NIPOq6IEYxPbKjtM6iiS+05zHJRAmFaFQSH13qnGQtC1+6lzyORP z23iQWefG1o4A== 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.98.2) (envelope-from ) id 1vhlit-00000003Wfc-0NBv; Mon, 19 Jan 2026 09:38:59 +0000 Date: Mon, 19 Jan 2026 09:38:58 +0000 Message-ID: <867btec571.wl-maz@kernel.org> From: Marc Zyngier To: Sascha Bischoff Cc: Andre Przywara , "will@kernel.org" , "julien.thierry.kdev@gmail.com" , "kvm@vger.kernel.org" , "kvmarm@lists.linux.dev" , Alexandru Elisei , nd Subject: Re: [PATCH kvmtool v4 5/7] arm64: Add FEAT_E2H0 support In-Reply-To: References: <20250924134511.4109935-1-andre.przywara@arm.com> <20250924134511.4109935-6-andre.przywara@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/30.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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: Sascha.Bischoff@arm.com, Andre.Przywara@arm.com, will@kernel.org, julien.thierry.kdev@gmail.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, Alexandru.Elisei@arm.com, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 16 Jan 2026 18:12:40 +0000, Sascha Bischoff wrote: >=20 > On Wed, 2025-09-24 at 14:45 +0100, Andre Przywara wrote: > > From: Marc Zyngier > >=20 > > The --nested option allows a guest to boot at EL2 without FEAT_E2H0 > > (i.e. mandating VHE support). While this is great for "modern" > > operating > > systems and hypervisors, a few legacy guests are stuck in a distant > > past. > >=20 > > To support those, add the --e2h0 command line option, that exposes > > FEAT_E2H0 to the guest, at the expense of a number of other features, > > such > > as FEAT_NV2. This is conditioned on the host itself supporting > > FEAT_E2H0. > >=20 > > Signed-off-by: Marc Zyngier > > Signed-off-by: Andre Przywara >=20 > One inline comment below, but irrespective: >=20 > Reviewed-by: Sascha Bischoff [...] > > diff --git a/arm64/kvm-cpu.c b/arm64/kvm-cpu.c > > index 42dc11dad..5e4f3a7dd 100644 > > --- a/arm64/kvm-cpu.c > > +++ b/arm64/kvm-cpu.c > > @@ -76,6 +76,11 @@ static void kvm_cpu__select_features(struct kvm > > *kvm, struct kvm_vcpu_init *init > > =C2=A0 if (!kvm__supports_extension(kvm, KVM_CAP_ARM_EL2)) > > =C2=A0 die("EL2 (nested virt) is not supported"); > > =C2=A0 init->features[0] |=3D 1UL << KVM_ARM_VCPU_HAS_EL2; > > + if (kvm->cfg.arch.e2h0) { > > + if (!kvm__supports_extension(kvm, > > KVM_CAP_ARM_EL2_E2H0)) > > + die("FEAT_E2H0 is not supported"); > > + init->features[0] |=3D 1UL << > > KVM_ARM_VCPU_HAS_EL2_E2H0; > > + } >=20 > --e2h0 is only consumed if --nested is also set (correctly so, by my > understanding & the KVM docs). >=20 > Maybe it is worth printing that it isn't consumed without --nested if > only --e2h0 is supplied? Avoids the user thinking that it has an effect > when it doesn't. (Alternatively, make --e2h0 imply --nested, but I'm > not a fan of that, personally.) Sure, I can add a warning indicating that the option is ignored. Thanks, M. --=20 Without deviation from the norm, progress is not possible.