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 5190925E83C; Fri, 20 Jun 2025 11:52:12 +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=1750420333; cv=none; b=hRN/IXW7M8heEoQelLsO/kFsLyjvC+2fF4W9twi7/H4LuKe1zDn2P6b/tv5YS88jLHvCoDPOFJbdONHn51kPPR0anEGwn6GcvNMhCKCdRBXuE1AcKx2m9/cdepq6wip4Zq+tN46H99WDMwOPBCmwY4Rh+iBJwqVMrmP36wXcJ5Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750420333; c=relaxed/simple; bh=a2kXmfRYhfHsg1B/+jNgwJYC8EaQFtK19/hEZabrmJs=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=YrtHp74l4y0CJJlY3nAKyBDmBl1E9FJazbuDyuPmrixf4Mr/Wj8nfTQvdbqMQ6Zqi9HZYVRVQ0V7XhYAi6nfc+6yq029tKZmwzBbnET8KvUbK6hoRa15E226rjDgrX0Jaq+ziS4fqfYLFoxvyrIyIDcqugQjGYdoMgNn4q5O0Gw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X/VEVYX8; 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="X/VEVYX8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B896FC4CEEE; Fri, 20 Jun 2025 11:52:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1750420332; bh=a2kXmfRYhfHsg1B/+jNgwJYC8EaQFtK19/hEZabrmJs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=X/VEVYX8aPDUQ//yRIoaTsoR8MiF6Bdbr5aElLqkZNonUtIkc4QBupwvFXkltIZ7r K8l3TV/2q4nli23LrW3f7YBBhsXG7NNvtWtH2o9pQnToUKy9DNKym1b1imEsLFS8T8 ltwgGTlDS3OLoFsBAo6AephRJzTyq2Tc4z2f/jVyOgJmVgM52US46xX4RrNDNmFSz2 s55zZwCDd9200gdnoT7qPpFg8/5pkCUhKKIL81eKeeRne04dgZTf70IlB1GnZTO9+m MJQOjXgcXuGGpXfM6FQIu9HYcGBif+pxPCr8+S8l8QJz51L5ci09oahqHn6xkHXUUj 8/JW3cl325iEw== 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 1uSaHy-008Xs6-El; Fri, 20 Jun 2025 12:52:10 +0100 Date: Fri, 20 Jun 2025 12:52:08 +0100 Message-ID: <86h60ad40n.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: Andre Przywara , Will Deacon , Julien Thierry , kvm@vger.kernel.org, kvmarm@lists.linux.dev Subject: Re: [PATCH kvmtool 2/3] arm64: Initial nested virt support In-Reply-To: References: <20250620104454.1384132-1-andre.przywara@arm.com> <20250620104454.1384132-3-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=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, andre.przywara@arm.com, will@kernel.org, julien.thierry.kdev@gmail.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 20 Jun 2025 12:09:38 +0100, Alexandru Elisei 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.