From: Marc Zyngier <maz@kernel.org>
To: James Clark <james.clark@linaro.org>
Cc: suzuki.poulose@arm.com, oliver.upton@linux.dev,
coresight@lists.linaro.org, kvmarm@lists.linux.dev,
Joey Gouly <joey.gouly@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Mike Leach <mike.leach@linaro.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Mark Rutland <mark.rutland@arm.com>,
Mark Brown <broonie@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
James Morse <james.morse@arm.com>, Fuad Tabba <tabba@google.com>,
Shiqi Liu <shiqiliu@hust.edu.cn>,
Raghavendra Rao Ananta <rananta@google.com>,
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
Date: Mon, 18 Nov 2024 09:00:41 +0000 [thread overview]
Message-ID: <86y11gvruu.wl-maz@kernel.org> (raw)
In-Reply-To: <20241112103717.589952-5-james.clark@linaro.org>
On Tue, 12 Nov 2024 10:37:03 +0000,
James Clark <james.clark@linaro.org> 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 <james.clark@linaro.org>
> ---
> 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.
next prev parent reply other threads:[~2024-11-18 9:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 10:36 [PATCH v7 00/12] kvm/coresight: Support exclude guest and exclude host James Clark
2024-11-12 10:37 ` [PATCH v7 01/12] arm64/sysreg: Add a comment that the sysreg file should be sorted James Clark
2024-11-12 10:37 ` [PATCH v7 02/12] tools: arm64: Update sysreg.h header files James Clark
2024-11-12 10:37 ` [PATCH v7 03/12] arm64/sysreg/tools: Move TRFCR definitions to sysreg James Clark
2024-11-12 10:37 ` [PATCH v7 04/12] KVM: arm64: Make vcpu flag macros more generic James Clark
2024-11-18 9:00 ` Marc Zyngier [this message]
2024-11-18 9:22 ` James Clark
2024-11-12 10:37 ` [PATCH v7 05/12] KVM: arm64: Move SPE and TRBE flags to host data James Clark
2024-11-12 10:37 ` [PATCH v7 06/12] KVM: arm64: Add flag for FEAT_TRF James Clark
2024-11-12 10:37 ` [PATCH v7 07/12] KVM: arm64: arm_spe: Give SPE enabled state to KVM James Clark
2024-11-20 9:16 ` Oliver Upton
2024-11-20 9:43 ` James Clark
2024-11-12 10:37 ` [PATCH v7 08/12] KVM: arm64: Don't hit sysregs to see if SPE is enabled or not James Clark
2024-11-12 10:37 ` [PATCH v7 09/12] KVM: arm64: coresight: Give TRBE enabled state to KVM James Clark
2024-11-12 10:37 ` [PATCH v7 10/12] KVM: arm64: Don't hit sysregs to see if TRBE is enabled or not James Clark
2024-11-12 10:37 ` [PATCH v7 11/12] KVM: arm64: Swap TRFCR on guest switch James Clark
2024-11-20 17:31 ` Oliver Upton
2024-11-21 12:50 ` James Clark
2024-11-26 16:23 ` Oliver Upton
2024-11-27 10:08 ` James Clark
2024-11-12 10:37 ` [PATCH v7 12/12] coresight: Pass guest TRFCR value to KVM James Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86y11gvruu.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=coresight@lists.linaro.org \
--cc=james.clark@linaro.org \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mike.leach@linaro.org \
--cc=oliver.upton@linux.dev \
--cc=rananta@google.com \
--cc=shiqiliu@hust.edu.cn \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).