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 89996D43FF2 for ; Mon, 18 Nov 2024 09:01:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=d9Qt+VbksJSzYU8yOYTLDYWvBV0qoRaTem+nkVDx9W4=; b=DCBOKrFoYvhKlv7ny/gvdBxb2T CGw8WxpnyDSawqwXncxPACQ2FkEgZ4OC2t2xqSbbfcqMuxh/zUHncBtPdY5J90BVF5jrZevGH/jTb YLINhfn+zFeTCN2JUwD7qNm8BS3+3iLTcHutUTI6a2yuf6X/ZLyjxFnNBWbgrYD7sO17/riAf5T5q XysRtUZtF5U7eLVJ90pr3US9ZLw+vMleaisUSk49FfrNXmhYpL/AXdVwBHA+ktFQkG0AV9mSzjORv gieKaBz4Om9J5PoRaub9FgO9gc81fUCKohsgg6XNe2EBJEEJMWsSs+eAWedTWtPaVMpoURpfIeAM6 WkiElsew==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tCxdf-00000008r5T-1gSm; Mon, 18 Nov 2024 09:01:43 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tCxcj-00000008qxs-3q6G for linux-arm-kernel@lists.infradead.org; Mon, 18 Nov 2024 09:00:47 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B512E5C57C8; Mon, 18 Nov 2024 09:00:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75D65C4CECC; Mon, 18 Nov 2024 09:00:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1731920444; bh=l9ycbKZl1O/s1sF56Ep8snxmvqADeI+bcDjz6IkJLv0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=c49nwjN+w56fry5JQGdarHi3gUObH15Pz3ygCTCD1AeLwBk0UzbSt7GG82voagb9m b6p7HrUmv4IKHyMFwVhMvlti5emv544Ui/NNAflz5s4fxRCQ+tr1zP1/S8xYMDnrAy 9+GD470KnTPoM1uXR9NY+BLyCBAudVfE1UExiN62dKmPaNaEmAFhq3n7JYqVyXP9hd eFysR+mBaCRxsWUypPCmdQ3S26ih93uP38MG8X+ihVgND7RRy7laohzQ35DVLYMa7z iIVwrPT28Awn7BS7y+6YdnsUYqNwA8CKAUYP/BNLsGGFA7Vwa7s8H/g9VxoJNC+EZp gzZ0uxaLjok+w== 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 1tCxcf-00DiQT-SA; Mon, 18 Nov 2024 09:00:42 +0000 Date: Mon, 18 Nov 2024 09:00:41 +0000 Message-ID: <86y11gvruu.wl-maz@kernel.org> From: Marc Zyngier To: James Clark Cc: suzuki.poulose@arm.com, oliver.upton@linux.dev, coresight@lists.linaro.org, kvmarm@lists.linux.dev, Joey Gouly , Zenghui Yu , Catalin Marinas , Will Deacon , Mike Leach , Alexander Shishkin , Mark Rutland , Mark Brown , Anshuman Khandual , James Morse , Fuad Tabba , Shiqi Liu , Raghavendra Rao Ananta , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 04/12] KVM: arm64: Make vcpu flag macros more generic In-Reply-To: <20241112103717.589952-5-james.clark@linaro.org> References: <20241112103717.589952-1-james.clark@linaro.org> <20241112103717.589952-5-james.clark@linaro.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/29.4 (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: james.clark@linaro.org, suzuki.poulose@arm.com, oliver.upton@linux.dev, coresight@lists.linaro.org, kvmarm@lists.linux.dev, joey.gouly@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, mike.leach@linaro.org, alexander.shishkin@linux.intel.com, mark.rutland@arm.com, broonie@kernel.org, anshuman.khandual@arm.com, james.morse@arm.com, tabba@google.com, shiqiliu@hust.edu.cn, rananta@google.com, linux-arm-kernel@lists.infradead.org, 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-20241118_010046_041500_73DBA130 X-CRM114-Status: GOOD ( 27.69 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 12 Nov 2024 10:37:03 +0000, James Clark wrote: > > Rename vcpu_* to kvm_* so that the same flags mechanism can be used in > places other than vcpu without being confusing. Wherever macros are > still related to vcpu like vcpu_get_flag() with hard coded v->arch, keep > the vcpu_* name, otherwise change it. > > Also move the "v->arch" access one macro higher for the same reason. > > This will be used for moving flags to host_data in a later commit. > > Signed-off-by: James Clark > --- > arch/arm64/include/asm/kvm_host.h | 88 +++++++++++++++---------------- > arch/arm64/kvm/hyp/exception.c | 12 ++--- > arch/arm64/kvm/inject_fault.c | 4 +- > arch/arm64/kvm/mmio.c | 10 ++-- > 4 files changed, 57 insertions(+), 57 deletions(-) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index f333b189fb43..34aa59f498c4 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -790,22 +790,22 @@ struct kvm_vcpu_arch { > /* > * Each 'flag' is composed of a comma-separated triplet: > * > - * - the flag-set it belongs to in the vcpu->arch structure > + * - the flag-set it belongs to in the structure pointed to by 'v' > * - the value for that flag > * - the mask for that flag > * > - * __vcpu_single_flag() builds such a triplet for a single-bit flag. > - * unpack_vcpu_flag() extract the flag value from the triplet for > + * __kvm_single_flag() builds such a triplet for a single-bit flag. > + * unpack_kvm_flag() extract the flag value from the triplet for > * direct use outside of the flag accessors. > */ > -#define __vcpu_single_flag(_set, _f) _set, (_f), (_f) > +#define __kvm_single_flag(_set, _f) _set, (_f), (_f) > > #define __unpack_flag(_set, _f, _m) _f > -#define unpack_vcpu_flag(...) __unpack_flag(__VA_ARGS__) > +#define unpack_kvm_flag(...) __unpack_flag(__VA_ARGS__) > > #define __build_check_flag(v, flagset, f, m) \ > do { \ > - typeof(v->arch.flagset) *_fset; \ > + typeof(v.flagset) *_fset; \ > \ > /* Check that the flags fit in the mask */ \ > BUILD_BUG_ON(HWEIGHT(m) != HWEIGHT((f) | (m))); \ > @@ -813,11 +813,11 @@ struct kvm_vcpu_arch { > BUILD_BUG_ON((sizeof(*_fset) * 8) <= __fls(m)); \ > } while (0) > > -#define __vcpu_get_flag(v, flagset, f, m) \ > +#define __kvm_get_flag(v, flagset, f, m) \ > ({ \ > __build_check_flag(v, flagset, f, m); \ > \ > - READ_ONCE(v->arch.flagset) & (m); \ > + READ_ONCE(v.flagset) & (m); \ > }) > > /* > @@ -826,64 +826,64 @@ struct kvm_vcpu_arch { > */ > #ifdef __KVM_NVHE_HYPERVISOR__ > /* the nVHE hypervisor is always non-preemptible */ > -#define __vcpu_flags_preempt_disable() > -#define __vcpu_flags_preempt_enable() > +#define __kvm_flags_preempt_disable() > +#define __kvm_flags_preempt_enable() > #else > -#define __vcpu_flags_preempt_disable() preempt_disable() > -#define __vcpu_flags_preempt_enable() preempt_enable() > +#define __kvm_flags_preempt_disable() preempt_disable() > +#define __kvm_flags_preempt_enable() preempt_enable() > #endif > > -#define __vcpu_set_flag(v, flagset, f, m) \ > +#define __kvm_set_flag(v, flagset, f, m) \ Hell no. Never. The whole point of this naming is that we know what this applies to. Here, you might as well have replaced 'vcpu' with 'carrot', and the result would be the same. Not to mention the insane churn this generates. So no, not happening. M. -- Without deviation from the norm, progress is not possible.