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 9BA6EC4332F for ; Thu, 22 Dec 2022 12:24:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235259AbiLVMYA (ORCPT ); Thu, 22 Dec 2022 07:24:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235264AbiLVMXy (ORCPT ); Thu, 22 Dec 2022 07:23:54 -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 C8FDF19003 for ; Thu, 22 Dec 2022 04:23:53 -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 10C1761B11 for ; Thu, 22 Dec 2022 12:23:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65329C433D2; Thu, 22 Dec 2022 12:23:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671711832; bh=ub1l/0iM010zyPkMwuC5cprfkrYFEiJ/6duRHQ7gLP0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Qsx2KqYbiwDRCgsNrK135M+6sHIp8T78Kj8DOFlnx31F+x00m2sLHpWlj0UB/tn9B 022L4tqz3pCnQJKLbSSeFNuXPDqolzwrsoneP2hOwzgoURbXBHrHRMRiyGsHLJXR81 Oqp49gj7fJGvxPQTFfzM3ANigCCBj1lCC1JOdzNUa+97ZjZDVHwiuuwVcoBMZYfWVH pZuEg6Bjge0T0tQVrStohBaM+6BnShgfNg8qN/8VcrBzey3uVQ06HkmbpDABUPaZVq vOgP/iGUILxBrZTCbD802dGA40umqKRTt+L4oum1j99gw2yy0E1eEFhvygfuRQSzqM EzogaH3deVkuQ== 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 1p8Kc1-00ENKb-TG; Thu, 22 Dec 2022 12:23:49 +0000 Date: Thu, 22 Dec 2022 12:23:49 +0000 Message-ID: <86h6xnbp9m.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: James Morse , Alexandru Elisei , Suzuki K Poulose , Oliver Upton , Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] KVM: arm64: Remove use of ARM64_FEATURE_MASK() In-Reply-To: <20221221-kvm-sysreg-cleanup-v1-2-112ddb14fb4e@kernel.org> References: <20221221-kvm-sysreg-cleanup-v1-0-112ddb14fb4e@kernel.org> <20221221-kvm-sysreg-cleanup-v1-2-112ddb14fb4e@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/28.2 (aarch64-unknown-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: broonie@kernel.org, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org 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: linux-kernel@vger.kernel.org On Wed, 21 Dec 2022 18:06:10 +0000, Mark Brown wrote: > > The KVM code makes extensive use of ARM64_FEATURE_MASK() to generate a > mask for fields in the ID registers. This macro has the assumption that > all feature fields are 4 bits wide but the architecture has evolved to > add fields with other widths, such as the 1 bit fields in ID_AA64SMFR0_EL1, > so we need to adjust the > > We could fix this by making ARM64_FEATURE_MASK() use the generated macros > that we have now but since one of these is a direct _MASK constant the > result is something that's more verbose and less direct than just updating > the users to directly use the generated mask macros, writing > > #define ARM64_FEATURE_MASK(x) (x##_MASK) > > obviously looks redundant and if we look at the users updating them turns > > val &= ~ARM64_FEATURE_MASK(ID_AA64PFR0_EL1_CSV3); > > into the more direct > > val &= ~ID_AA64PFR0_EL1_CSV3_MASK; If the two are strictly equivalent, then let's use the former as it results in a tiny diff. Constantly repainting these files causes no end of conflicts when rebasing large series (pKVM, NV...), and makes backporting of fixes much harder than it should be. Specially considering that there is a single occcurence of an ID register with non-4bit fields. Just put a FIXME in the various files so that people do the repainting as they change this code. Thanks, M. -- Without deviation from the norm, progress is not possible.