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 A56C1C46CD2 for ; Tue, 9 Jan 2024 15:16:56 +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=LoErwarf/4uOgskVhwWDjp7QSW9e8yPOKQiVPePBIqs=; b=4AZ6uvcRnVl5Rh YuwxnMJ64ojAtjjSYHA9SZJVAXKxiXZMR5WXraRetE6QvrZCoQqXSxNacicEYsLX2qfU6b1eDpjrp H39+uKJAxtU21xYp/5RJ9x8I6CKmky8D0VLLurlK5tWlx8/1rauZGlwQAMZ/ZrD/XqGJS/JspmSsu 8RtQJPoB5hxIBfsE4+jBTWATYWSQByigbjADf3BfQGMXVFo/EMyecwu5t62aBlxvGd4zj724YZGWW JO0urnyURYasMh0s/zDceAtIAW//fSxrR/wZbJVm6HX+FTYmh4rRI5Bq9cimp8ERazE3CzuWQVG68 8S602I+ZAOBLp5341J1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rNDq4-008dK0-1Z; Tue, 09 Jan 2024 15:16:24 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rNDq0-008dI1-2d for linux-arm-kernel@lists.infradead.org; Tue, 09 Jan 2024 15:16:22 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 704A4CE1914; Tue, 9 Jan 2024 15:16:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86619C433C7; Tue, 9 Jan 2024 15:16:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704813376; bh=u3VxjdwAl9+MAihzbY3LBWNdZrbXgO8eh6jTlVT3WgU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ae3nJ9d2+bxrz0vghfnVG3XlG8L32Jynf6KZOhZVGpuSiVkBxq0rwwW+ei5TtT7QP JDvyQg09nGZS9hmR/Iya/5psk52BmkykgKZ6uFwStLiy3AnKs3J1k1FUPktjLfCIwz 2Fov79wuZr8XAup/rvGBqjDyWA0GPHPerzvCM1Oc0mJVNaXzu3dsEoIF+3eMj1vmEm ygAwuZz2m7QQGFapZotCxkMksXRrewyjgMO/onHG6PnhVTTQ/w66+ZPuPFnWAW2t/P RC12z7c6X7e+UaNbJH/FO+KatPRocsgZczvFG9K/UWGjbnDz2zvo4kSwsRSI2YAQgS zrnGtu5mzjC3w== 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 1rNDpt-00ADtY-Uv; Tue, 09 Jan 2024 15:16:14 +0000 Date: Tue, 09 Jan 2024 15:16:13 +0000 Message-ID: <868r4ya66a.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, Catalin Marinas , Mark Rutland , Ard Biesheuvel , James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: Re: [PATCH v3 06/13] arm64: cpufeature: Detect E2H0 not being implemented In-Reply-To: <20231211124238.GB25277@willie-the-truck> References: <20231127114559.990314-1-maz@kernel.org> <20231127114559.990314-7-maz@kernel.org> <20231211124238.GB25277@willie-the-truck> 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: will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, catalin.marinas@arm.com, mark.rutland@arm.com, ardb@kernel.org, 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-20240109_071621_205653_6C4ABBEC X-CRM114-Status: GOOD ( 30.57 ) 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 Mon, 11 Dec 2023 12:42:38 +0000, Will Deacon wrote: > > On Mon, Nov 27, 2023 at 11:45:52AM +0000, Marc Zyngier wrote: > > FEAT_E2H0 is a new feature that indicates whether or not HCR_EL2.E2H > > can be set to 0. Amusingly, this feature is set to 0 when implemented, > > and otherwise negative. > > > > Add a new capability and detection infrastructure to detect the > > absence of FEAT_E2H0. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kernel/cpufeature.c | 7 +++++++ > > arch/arm64/tools/cpucaps | 1 + > > 2 files changed, 8 insertions(+) > > > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > > index 4a72fb26daec..6ef9811f7bb7 100644 > > --- a/arch/arm64/kernel/cpufeature.c > > +++ b/arch/arm64/kernel/cpufeature.c > > @@ -2786,6 +2786,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = { > > .matches = has_cpuid_feature, > > ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP) > > }, > > + { > > + .desc = "FEAT_E2H0 not implemented", > > + .capability = ARM64_HCR_E2H_RES1, > > + .type = ARM64_CPUCAP_SYSTEM_FEATURE, > > Is ARM64_CPUCAP_SYSTEM_FEATURE the right thing to use here? For example, > if the boot CPUs have this feature but a late CPU doesn't, then I think > we should be ok as long as we're using VHE, but I don't think the above > takes that into account. > > Maybe we shouldn't be adding new capabilities for this at all, and instead > just look at the sanitised register value when we need to? That's probably good enough for this particular use of E2H0, as this is not used on any fast path. However, when E2H0 is 0b1110 (NV1 being RES0, and thus the guest's own HCR_EL2.E2H being RES1), we need to sanitise the guest's HCR_EL2 no matter what the guest writes there. With that in mind, __vcpu_el2_e2h_is_set() using the sanitised value would result in a binary search on a lot of very hot paths, something that I'm keen to avoid. So while I'm happy to drop this particular cap, I'll keep the one introduced in patch #6. Thanks, 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