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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2DE95C4332F for ; Thu, 13 Jan 2022 14:24:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 74A6549EF8; Thu, 13 Jan 2022 09:24:55 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fenujfU31Wh1; Thu, 13 Jan 2022 09:24:54 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 33D2849F3E; Thu, 13 Jan 2022 09:24:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C860349F0E for ; Thu, 13 Jan 2022 09:24:53 -0500 (EST) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeIL93RKGNU3 for ; Thu, 13 Jan 2022 09:24:52 -0500 (EST) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 9A24849EF8 for ; Thu, 13 Jan 2022 09:24:52 -0500 (EST) 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 ams.source.kernel.org (Postfix) with ESMTPS id 10371B82011; Thu, 13 Jan 2022 14:24:51 +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 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") 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 Cc: kvm@vger.kernel.org, Andre Przywara , Christoffer Dall , kvmarm@lists.cs.columbia.edu, Ganapatrao Kulkarni , kernel-team@android.com, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm