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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9216FC54FB9 for ; Tue, 21 Nov 2023 09:27:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UoPn8tLMzVlq4x/olu/k2xubT30+WkbmC0TX3iRGraA=; b=i+BPFXCbFSyuL7 VHTQdg46zwAfQR/L9a6JJtkDgjANsZqnHJvdkkv7syf2wOOXD51YgJPa3iKbVPMaKROd8Ie3oBuMd Vxr7uzUg31bgrFF65D+9HUwCso92ZZ6ofZMRlTqAVSXqqDiCIU9T2og3kD+WVFafRXrxWLX61eg+y wSUIrEoVaDUG9/0IXCAGkH02gtJpuZQyOae+QVJWbAysMc9uvKCwrRFAnxxABGtWPUovZ55knuJDy 7PPa4Rwcx9Y+9pffQ6wGB/ae7PhA+JES2UJsG7R1z7bXTTR+FFb6fS4aa1uGi3icbttI6dgQmqB2I As+ewxFP1Uv+3fVkBotw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r5N2M-00G87M-1j; Tue, 21 Nov 2023 09:27:18 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r5N2J-00G86Y-1x for linux-arm-kernel@lists.infradead.org; Tue, 21 Nov 2023 09:27:17 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 04CF860BA3; Tue, 21 Nov 2023 09:27:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8FC2C433C8; Tue, 21 Nov 2023 09:27:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700558833; bh=oYIQI8oRhTi2tBjIzh/yvP0I8sqoKDxOvxxRl8mbGwI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Nm7fcIakdUO6O6TnwrI4vWIlSHpjpSUTT9BgASMU0Vbj/V31qVMeUUTowvOGw7HCh 0SyVMarE+F9YX9THyYSWlRvKDNbojvNUFPEqGbyUW1ZhHTNhoEp5jcJgyHERPhQiKI cdWOpj5q4se+IX2dxvb3wK70kOjNOHPpsNrB6Tzoq9H0wuhMgi+Wm+BuEuk3pBYQnv um/z1EuUaRqgy+YxbDB2TkoWtJchyxt23R+8Q9tCtEZi2FbN8OSvIqwuKj22ZO15Bh OLrzrctbZtaVLcnb1aQjD14tBg0B8ttLgCe1+s3zYn4/975gaFydQUfs8FJ4cX87IG hX9AnEZr2CWZw== 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 1r5N2E-00F137-Mo; Tue, 21 Nov 2023 09:27:10 +0000 Date: Tue, 21 Nov 2023 09:27:10 +0000 Message-ID: <86sf4zzcb5.wl-maz@kernel.org> From: Marc Zyngier To: Ganapatrao Kulkarni Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Alexandru Elisei , Andre Przywara , Chase Conklin , Christoffer Dall , Darren Hart , Jintack Lim , Russell King , Miguel Luis , James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: Re: [PATCH v11 01/43] arm64: cpufeatures: Restrict NV support to FEAT_NV2 In-Reply-To: <2e25b427-9df6-42f7-99b3-bb2d01a0f0c4@os.amperecomputing.com> References: <20231120131027.854038-1-maz@kernel.org> <20231120131027.854038-2-maz@kernel.org> <2e25b427-9df6-42f7-99b3-bb2d01a0f0c4@os.amperecomputing.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/29.1 (aarch64-unknown-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: gankulkarni@os.amperecomputing.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, alexandru.elisei@arm.com, andre.przywara@arm.com, chase.conklin@arm.com, christoffer.dall@arm.com, darren@os.amperecomputing.com, jintack@cs.columbia.edu, rmk+kernel@armlinux.org.uk, miguel.luis@oracle.com, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231121_012715_750186_2C99F1C1 X-CRM114-Status: GOOD ( 30.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 21 Nov 2023 09:07:30 +0000, Ganapatrao Kulkarni wrote: > > > > On 20-11-2023 06:39 pm, Marc Zyngier wrote: > > To anyone who has played with FEAT_NV, it is obvious that the level > > of performance is rather low due to the trap amplification that it > > imposes on the host hypervisor. FEAT_NV2 solves a number of the > > problems that FEAT_NV had. > > > > It also turns out that all the existing hardware that has FEAT_NV > > also has FEAT_NV2. Finally, it is now allowed by the architecture > > to build FEAT_NV2 *only* (as denoted by ID_AA64MMFR4_EL1.NV_frac), > > which effectively seals the fate of FEAT_NV. > > > > Restrict the NV support to NV2, and be done with it. Nobody will > > cry over the old crap. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kernel/cpufeature.c | 22 +++++++++++++++------- > > arch/arm64/tools/cpucaps | 2 ++ > > 2 files changed, 17 insertions(+), 7 deletions(-) > > > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > > index 7dcda39537f8..95a677cf8c04 100644 > > --- a/arch/arm64/kernel/cpufeature.c > > +++ b/arch/arm64/kernel/cpufeature.c > > @@ -439,6 +439,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr3[] = { > > static const struct arm64_ftr_bits ftr_id_aa64mmfr4[] = { > > S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR4_EL1_E2H0_SHIFT, 4, 0), > > + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_HIGHER_SAFE, ID_AA64MMFR4_EL1_NV_frac_SHIFT, 4, 0), > > ARM64_FTR_END, > > }; > > @@ -2080,12 +2081,8 @@ static bool has_nested_virt_support(const > > struct arm64_cpu_capabilities *cap, > > if (kvm_get_mode() != KVM_MODE_NV) > > return false; > > - if (!has_cpuid_feature(cap, scope)) { > > - pr_warn("unavailable: %s\n", cap->desc); > > - return false; > > - } > > - > > - return true; > > + return (__system_matches_cap(ARM64_HAS_NV2) | > > + __system_matches_cap(ARM64_HAS_NV2_ONLY)); > > This seems to be typo and should it be logical OR? Indeed, this is a bug. Not that it will have any effect as __system_matches_cap() returns a bool, so | and || are strictly equivalent. Worth addressing though. > > > } > > static bool hvhe_possible(const struct arm64_cpu_capabilities > > *entry, > > @@ -2391,12 +2388,23 @@ static const struct arm64_cpu_capabilities arm64_features[] = { > > .matches = runs_at_el2, > > .cpu_enable = cpu_copy_el2regs, > > }, > > + { > > + .capability = ARM64_HAS_NV2, > > + .type = ARM64_CPUCAP_SYSTEM_FEATURE, > > + .matches = has_cpuid_feature, > > + ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, NV, NV2) > > + }, > > + { > > + .capability = ARM64_HAS_NV2_ONLY, > > + .type = ARM64_CPUCAP_SYSTEM_FEATURE, > > + .matches = has_cpuid_feature, > > + ARM64_CPUID_FIELDS(ID_AA64MMFR4_EL1, NV_frac, NV2_ONLY) > > + }, > > { > > .desc = "Nested Virtualization Support", > > .capability = ARM64_HAS_NESTED_VIRT, > > .type = ARM64_CPUCAP_SYSTEM_FEATURE, > > .matches = has_nested_virt_support, > > - ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, NV, IMP) > > Since only NV2 is supported, is it more appropriate to have > description as "Enhanced Nested Virtualization Support"? Nah. There is nothing 'enhanced' about NV2. It is NV that should have been named "Unusable Nested Virt"... So I'm perfectly happy to leave it as is. And to be honest, I'd rather we display FEAT_* rather than some interpretation of it, but I'm not going to repaint cpufeature.c. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel