From mboxrd@z Thu Jan 1 00:00:00 1970 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A1F1C433FE for ; Thu, 13 Jan 2022 14:24:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235651AbiAMOYw (ORCPT ); Thu, 13 Jan 2022 09:24:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235649AbiAMOYv (ORCPT ); Thu, 13 Jan 2022 09:24:51 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00E41C06173F for ; Thu, 13 Jan 2022 06:24:50 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6155561CCC for ; Thu, 13 Jan 2022 14:24:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE1BBC36AE9; Thu, 13 Jan 2022 14:24:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642083889; bh=svbuPhCXep/f7L7EOte2zVLFwttWAAhq8yFpX/SSd3w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=GtfqDh2n3X2nUJRLn8kjbYNFkij+XoDuBYTNSyOp//OGEro6wYg7Y+jqCnjG02BQU BwhZB46if2yV5RsC16ZBlsT3BLHPe6N+s/x21QhEwhCdcaQEYr2S6NZoj8njavQb51 Q8bN5lWrl0tFJhGJX/Ssfrnj1th7njhBkxqp4cbIUq8+REpTa6G9jkGYN4p6CLN0wg zxm7WNJ+2sGiT+RrylXIxsxXYdCDNAL2YiESbcNhLjnosxH7O1MnfiFlK+MrqqcGYB aFBTfOzTqftWZxzwHx3MyRpY3BjZhREpqDNgCB3jjNdF/NzFz9W7whc3U233KRRI/6 aU6HjznepybOA== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n811z-000Ibp-Nj; Thu, 13 Jan 2022 14:24:47 +0000 Date: Thu, 13 Jan 2022 14:24:47 +0000 Message-ID: <87mtjz90i8.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Andre Przywara , Christoffer Dall , Jintack Lim , Haibo Xu , Ganapatrao Kulkarni , James Morse , Suzuki K Poulose , kernel-team@android.com Subject: Re: [PATCH v5 07/69] KVM: arm64: nv: Introduce nested virtualization VCPU feature In-Reply-To: References: <20211129200150.351436-1-maz@kernel.org> <20211129200150.351436-8-maz@kernel.org> 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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) 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, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, andre.przywara@arm.com, christoffer.dall@arm.com, jintack@cs.columbia.edu, haibo.xu@linaro.org, gankulkarni@os.amperecomputing.com, james.morse@arm.com, suzuki.poulose@arm.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, 13 Jan 2022 14:10:39 +0000, Alexandru Elisei wrote: > > Hi Marc, > > On Mon, Nov 29, 2021 at 08:00:48PM +0000, Marc Zyngier wrote: > > From: Christoffer Dall > > > > Introduce the feature bit and a primitive that checks if the feature is > > set behind a static key check based on the cpus_have_const_cap check. > > > > Checking nested_virt_in_use() on systems without nested virt enabled > > should have neglgible overhead. > > > > We don't yet allow userspace to actually set this feature. > > > > Signed-off-by: Christoffer Dall > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/include/asm/kvm_nested.h | 14 ++++++++++++++ > > arch/arm64/include/uapi/asm/kvm.h | 1 + > > 2 files changed, 15 insertions(+) > > create mode 100644 arch/arm64/include/asm/kvm_nested.h > > > > diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h > > new file mode 100644 > > index 000000000000..1028ac65a897 > > --- /dev/null > > +++ b/arch/arm64/include/asm/kvm_nested.h > > @@ -0,0 +1,14 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +#ifndef __ARM64_KVM_NESTED_H > > +#define __ARM64_KVM_NESTED_H > > + > > +#include > > + > > +static inline bool nested_virt_in_use(const struct kvm_vcpu *vcpu) > > +{ > > + return (!__is_defined(__KVM_NVHE_HYPERVISOR__) && > > + cpus_have_final_cap(ARM64_HAS_NESTED_VIRT) && > > + test_bit(KVM_ARM_VCPU_HAS_EL2, vcpu->arch.features)); > > kvm_vcpu_init_nested() checks the ARM64_HAS_NESTED_VIRT cap before setting > the features bit, so I guess you can drop this check here if you're > interested in correctness. > > But the reason the cap check done is performance, right? Same with the NVHE > define. Exactly. The capability check allows us to use a static key to bypass the test_bit() when NV isn't enable, which is 100% of our use cases. Given that this checked fairly often on some of the fast paths, it is worth doing it. The NVHE check goes even further by allowing some dead code removal in the nVHE-specific code, which cannot use NV by construction. Thanks, M. -- Without deviation from the norm, progress is not possible.