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 1FDFCC4332F for ; Thu, 22 Dec 2022 12:23:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 87A324BA91; Thu, 22 Dec 2022 07:23:57 -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 0nxeOuQ84jsw; Thu, 22 Dec 2022 07:23:56 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 5927C4BA25; Thu, 22 Dec 2022 07:23:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0102E4B9EA for ; Thu, 22 Dec 2022 07:23:55 -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 yvKfGZznwQnN for ; Thu, 22 Dec 2022 07:23:54 -0500 (EST) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id ED3DD4BA25 for ; Thu, 22 Dec 2022 07:23:53 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 0904D61AAF; 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 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") 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 Cc: Will Deacon , linux-kernel@vger.kernel.org, Catalin Marinas , kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, 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 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. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA5F433D2 for ; Thu, 22 Dec 2022 12:23:52 +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) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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 Message-ID: <20221222122349.1SfgeZQxUmkU1Um2OupufKXFW-vvPQbq2eq3eytWv2Q@z> 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. 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 BBE3CC4332F for ; Thu, 22 Dec 2022 13:37:38 +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=QhLrhw5RmidsqXGegvztC12eYYIOBBkYDL8cqethIoM=; b=PR/4qx+w3tDrbZ 00Olhje7VoPyHZQ+qYHAHuQ0NgsBvlTCPM0G98ZaJDMg5FJCZLK8Zif/98zYFzse5uPt39XqTDEmh shr25d3AVIugAawyOtwsVXCQdOH3BpAyRr2KYODBCM23FbABFkjyBaVhrNxxKqPAu1hJwM1NFEs+Z r4Z8vu2xTKr4anPbBmLuXGfUFBycq5h/C1/l0/54sy4ZJPbv/P1hc5JOrE1uJEbclsuzcnLHT+XCI oaahTg/KOauMn3yujH0obYgoi1XpyaGzHtWee4R3GwyI8327dh9pWHbbRoYPojL2jdwhTzbmcov8b Bdz3DhrkHspDtTkbv8lw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p8Ljv-00CT1z-Rb; Thu, 22 Dec 2022 13:36:04 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p8Kc6-00Bope-9v for linux-arm-kernel@lists.infradead.org; Thu, 22 Dec 2022 12:23:56 +0000 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 0904D61AAF; 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") 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221222_042354_845808_E4487797 X-CRM114-Status: GOOD ( 21.68 ) 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 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel