Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: Andre Przywara <andre.przywara@arm.com>,
	Will Deacon <will@kernel.org>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	kvm@vger.kernel.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH kvmtool 2/3] arm64: Initial nested virt support
Date: Fri, 20 Jun 2025 12:52:08 +0100	[thread overview]
Message-ID: <86h60ad40n.wl-maz@kernel.org> (raw)
In-Reply-To: <aFVBckcGYQgF+UXO@arm.com>

On Fri, 20 Jun 2025 12:09:38 +0100,
Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> 
> Hi Andre,
> 
> Thanks for doing this, it was needed. Haven't given this a proper look (I'm
> planning to do that though!), but something jumped at me, below.
> 
> On Fri, Jun 20, 2025 at 11:44:53AM +0100, Andre Przywara wrote:
> > The ARMv8.3 architecture update includes support for nested
> > virtualization. Allow the user to specify "--nested" to start a guest in
> 
> './vm help run' shows:
> 
> --pmu             Create PMUv3 device
> --disable-mte     Disable Memory Tagging Extension
> --no-pvtime       Disable stolen time
> 
> Where:
> 
> --pmu checks for KVM_CAP_ARM_PMU_V3.
> --disable-mte is there because MTE is enabled automatically for a guest when
> KVM_CAP_ARM_MTE is present.
> --no-pvtime is there because pvtime is enabled automatically; no capability
> check is needed, but the control group for pvtime is called
> KVM_ARM_VCPU_PVTIME_CTRL.
> 
> What I'm trying to get at is that the name for the kvmtool command line option
> matches KVM's name for the capability. What do you think about naming the
> parameter --el2 to match KVM_CAP_ARM_EL2 instead of --nested?
> 
>  Also, I seem to remember that the command line option for enabling
>  KVM_CAP_ARM_EL2_E2H0 in Marc's repo is --e2h0, so having --el2 instead of
>  --nested looks somewhat more consistent to me.
> 
>  Thoughts?

I think --el2 describes the wrong thing. We don't only expose EL2 to a
guest, but we also expose FEAT_NV2 by default. So "nested" is IMO
closer to the effects of the capability. If anything, it is
KVM_CAP_ARM_EL2 that is badly named (yes, there is some history here,
but I'm not going to entertain changing the #define after 8 years).

Similarly, QEMU has "virtualization=on" as an indication that it
should engage NV, and not "el2=on".

If you wanted a pure --el2 flag, then it should engage NV just like
--nested does, but disable FEAT_NV2 in the idregs. This would give you
EL2 without recursive NV and HCR_EL2.E2H RES1.

Thanks,

	M.

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

  reply	other threads:[~2025-06-20 11:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-20 10:44 [PATCH kvmtool 0/3] arm64: Nested virtualization support Andre Przywara
2025-06-20 10:44 ` [PATCH kvmtool 1/3] Sync kernel UAPI headers with v6.16-rc1 Andre Przywara
2025-06-20 10:44 ` [PATCH kvmtool 2/3] arm64: Initial nested virt support Andre Przywara
2025-06-20 11:09   ` Alexandru Elisei
2025-06-20 11:52     ` Marc Zyngier [this message]
2025-06-20 13:43       ` Alexandru Elisei
2025-06-20 10:44 ` [PATCH kvmtool 3/3] arm64: nested: add support for setting maintenance IRQ Andre Przywara
2025-06-20 11:13 ` [PATCH kvmtool 0/3] arm64: Nested virtualization support Marc Zyngier

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=86h60ad40n.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