kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Will Deacon <will@kernel.org>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	kvm@vger.kernel.org, kvmarm@lists.linux.dev,
	Alexandru Elisei <alexandru.elisei@arm.com>
Subject: Re: [PATCH kvmtool v2 5/6] arm64: add FEAT_E2H0 support (TBC)
Date: Fri, 25 Jul 2025 17:37:12 +0100	[thread overview]
Message-ID: <86cy9o8bwn.wl-maz@kernel.org> (raw)
In-Reply-To: <20250725144100.2944226-6-andre.przywara@arm.com>

Hi Andre,

Thanks for picking this. A few nits below.

On Fri, 25 Jul 2025 15:40:59 +0100,
Andre Przywara <andre.przywara@arm.com> wrote:
> 
> From: Marc Zyngier <maz@kernel.org>
> 
> To reduce code complexity, KVM only supports nested virtualisation in
> VHE mode. So to allow recursive nested virtualisation, and be able to
> expose FEAT_NV2 to a guest, we must prevent a guest from turning off
> HCR_EL2.E2H, which is covered by not advertising the FEAT_E2H0 architecture
> feature.
> 
> To allow people to run a guest in non-VHE mode, KVM introduced the
> KVM_ARM_VCPU_HAS_EL2_E2H0 feature flag, which will allow control over
> HCR_EL2.E2H, but at the cost of turning off FEAT_NV2.

All of that has been captured at length in the kernel code, and I
think this is "too much information" for userspace. I'd rather we
stick to a pure description of what the various options mean to the
user.

> Add a kvmtool command line option "--e2h0" to set that feature bit when
> creating a guest, to gain non-VHE, but lose recursive nested virt.

How about:

"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.

 To support those, the --e2h0 option 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."

> 
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  arm64/include/kvm/kvm-config-arch.h | 5 ++++-
>  arm64/kvm-cpu.c                     | 2 ++
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/arm64/include/kvm/kvm-config-arch.h b/arm64/include/kvm/kvm-config-arch.h
> index 44c43367b..73bf4211a 100644
> --- a/arm64/include/kvm/kvm-config-arch.h
> +++ b/arm64/include/kvm/kvm-config-arch.h
> @@ -11,6 +11,7 @@ struct kvm_config_arch {
>  	bool		has_pmuv3;
>  	bool		mte_disabled;
>  	bool		nested_virt;
> +	bool		e2h0;
>  	u64		kaslr_seed;
>  	enum irqchip_type irqchip;
>  	u64		fw_addr;
> @@ -63,6 +64,8 @@ int sve_vl_parser(const struct option *opt, const char *arg, int unset);
>  	OPT_U64('\0', "counter-offset", &(cfg)->counter_offset,			\
>  		"Specify the counter offset, defaulting to 0"),			\
>  	OPT_BOOLEAN('\0', "nested", &(cfg)->nested_virt,			\
> -		    "Start VCPUs in EL2 (for nested virt)"),
> +		    "Start VCPUs in EL2 (for nested virt)"),			\
> +	OPT_BOOLEAN('\0', "e2h0", &(cfg)->e2h0,					\
> +		    "Create guest without VHE support"),
>  
>  #endif /* ARM_COMMON__KVM_CONFIG_ARCH_H */
> diff --git a/arm64/kvm-cpu.c b/arm64/kvm-cpu.c
> index 42dc11dad..6eb76dff4 100644
> --- a/arm64/kvm-cpu.c
> +++ b/arm64/kvm-cpu.c
> @@ -76,6 +76,8 @@ static void kvm_cpu__select_features(struct kvm *kvm, struct kvm_vcpu_init *init
>  		if (!kvm__supports_extension(kvm, KVM_CAP_ARM_EL2))
>  			die("EL2 (nested virt) is not supported");
>  		init->features[0] |= 1UL << KVM_ARM_VCPU_HAS_EL2;
> +		if (kvm->cfg.arch.e2h0)
> +			init->features[0] |= 1UL << KVM_ARM_VCPU_HAS_EL2_E2H0;

This really should also check the capability in order to fail
gracefully on system that have no E2H0 support at all (or have it so
buggy that it is permanently disabled by the kernel):

+		if (kvm->cfg.arch.e2h0) {
+	  		if (!kvm__supports_extension(kvm, KVM_CAP_ARM_EL2_E2H0))
+				die("FEAT_E2H0 is not supported");
+			init->features[0] |= 1UL << KVM_ARM_VCPU_HAS_EL2_E2H0;
+		}

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2025-07-25 16:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-25 14:40 [PATCH kvmtool v2 0/6] arm64: Nested virtualization support Andre Przywara
2025-07-25 14:40 ` [PATCH kvmtool v2 1/6] Sync kernel UAPI headers with v6.16-rc1 Andre Przywara
2025-07-25 14:40 ` [PATCH kvmtool v2 2/6] arm64: Initial nested virt support Andre Przywara
2025-07-25 14:40 ` [PATCH kvmtool v2 3/6] arm64: nested: add support for setting maintenance IRQ Andre Przywara
2025-07-25 14:40 ` [PATCH kvmtool v2 4/6] arm64: Add counter offset control Andre Przywara
2025-07-26  9:25   ` Marc Zyngier
2025-07-25 14:40 ` [PATCH kvmtool v2 5/6] arm64: add FEAT_E2H0 support (TBC) Andre Przywara
2025-07-25 16:37   ` Marc Zyngier [this message]
2025-07-26  9:01     ` Wei-Lin Chang
2025-07-26  9:19       ` Marc Zyngier
2025-07-26 10:11         ` Wei-Lin Chang
2025-07-26 10:34           ` Marc Zyngier
2025-07-25 14:41 ` [PATCH kvmtool v2 6/6] arm64: Generate HYP timer interrupt specifiers Andre Przywara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86cy9o8bwn.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=andre.przywara@arm.com \
    --cc=julien.thierry.kdev@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).