From: Heiko Carstens <hca@linux.ibm.com>
To: Steffen Eiden <seiden@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Janosch Frank <frankja@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, nrb@linux.ibm.com
Subject: Re: [PATCH 1/3] s390/cpufeature: rework to allow more than only hwcap bits
Date: Tue, 12 Jul 2022 21:25:43 +0200 [thread overview]
Message-ID: <Ys3Kt7nG2jtE8H3H@osiris> (raw)
In-Reply-To: <20220712105220.325010-2-seiden@linux.ibm.com>
On Tue, Jul 12, 2022 at 12:52:18PM +0200, Steffen Eiden wrote:
> Rework cpufeature implementation to allow for various cpu feature
> indications, which is not only limited to hwcap bits. This is achieved
> by adding a sequential list of cpu feature numbers, where each of them
> is mapped to an entry which indicates what this number is about.
>
> Each entry contains a type member, which indicates what feature
> name space to look into (e.g. hwcap, or cpu facility). If wanted this
> allows also to automatically load modules only in e.g. z/VM
> configurations.
>
> Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
...
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright IBM Corp. 2022
> + * Author(s): Steffen Eiden <seiden@linux.ibm.com>
> + * Heiko Carstens <hca@linux.ibm.com>
Please don't add my name + email address in source code. I just
recently removed that everywhere since email addresses may change, and
git history is more than enough for me. It's up to you if you want to
keep your name + email address here.
> +static struct s390_cpu_feature s390_cpu_features[MAX_CPU_FEATURES] = {
> + [S390_CPU_FEATURE_ESAN3] = {.type = TYPE_HWCAP, .num = HWCAP_NR_ESAN3},
> + [S390_CPU_FEATURE_ZARCH] = {.type = TYPE_HWCAP, .num = HWCAP_NR_ZARCH},
> + [S390_CPU_FEATURE_STFLE] = {.type = TYPE_HWCAP, .num = HWCAP_NR_STFLE},
> + [S390_CPU_FEATURE_MSA] = {.type = TYPE_HWCAP, .num = HWCAP_NR_MSA},
> + [S390_CPU_FEATURE_LDISP] = {.type = TYPE_HWCAP, .num = HWCAP_NR_LDISP},
> + [S390_CPU_FEATURE_EIMM] = {.type = TYPE_HWCAP, .num = HWCAP_NR_EIMM},
> + [S390_CPU_FEATURE_DFP] = {.type = TYPE_HWCAP, .num = HWCAP_NR_DFP},
> + [S390_CPU_FEATURE_HPAGE] = {.type = TYPE_HWCAP, .num = HWCAP_NR_HPAGE},
> + [S390_CPU_FEATURE_ETF3EH] = {.type = TYPE_HWCAP, .num = HWCAP_NR_ETF3EH},
> + [S390_CPU_FEATURE_HIGH_GPRS] = {.type = TYPE_HWCAP, .num = HWCAP_NR_HIGH_GPRS},
> + [S390_CPU_FEATURE_TE] = {.type = TYPE_HWCAP, .num = HWCAP_NR_TE},
> + [S390_CPU_FEATURE_VXRS] = {.type = TYPE_HWCAP, .num = HWCAP_NR_VXRS},
> + [S390_CPU_FEATURE_VXRS_BCD] = {.type = TYPE_HWCAP, .num = HWCAP_NR_VXRS_BCD},
> + [S390_CPU_FEATURE_VXRS_EXT] = {.type = TYPE_HWCAP, .num = HWCAP_NR_VXRS_EXT},
> + [S390_CPU_FEATURE_GS] = {.type = TYPE_HWCAP, .num = HWCAP_NR_GS},
> + [S390_CPU_FEATURE_VXRS_EXT2] = {.type = TYPE_HWCAP, .num = HWCAP_NR_VXRS_EXT2},
> + [S390_CPU_FEATURE_VXRS_PDE] = {.type = TYPE_HWCAP, .num = HWCAP_NR_VXRS_PDE},
> + [S390_CPU_FEATURE_SORT] = {.type = TYPE_HWCAP, .num = HWCAP_NR_SORT},
> + [S390_CPU_FEATURE_DFLT] = {.type = TYPE_HWCAP, .num = HWCAP_NR_DFLT},
> + [S390_CPU_FEATURE_VXRS_PDE2] = {.type = TYPE_HWCAP, .num = HWCAP_NR_VXRS_PDE2},
> + [S390_CPU_FEATURE_NNPA] = {.type = TYPE_HWCAP, .num = HWCAP_NR_NNPA},
> + [S390_CPU_FEATURE_PCI_MIO] = {.type = TYPE_HWCAP, .num = HWCAP_NR_PCI_MIO},
> + [S390_CPU_FEATURE_SIE] = {.type = TYPE_HWCAP, .num = HWCAP_NR_SIE},
> +};
I only realized now that you added all HWCAP bits here. It was
intentional that I added only the two bits which are currently used
for several reasons:
- Keep the array as small as possible.
- No need to keep this array in sync with HWCAPs, if new ones are added.
- There is a for loop in print_cpu_modalias() which iterates over all
MAX_CPU_FEATURES entries; this should be as fast as possible. Adding
extra entries burns cycles for no added value.
Any future user which requires a not yet listed feature, can simply
add it when needed.
> +int cpu_have_feature(unsigned int num)
> +{
> + struct s390_cpu_feature *feature;
> +
> + feature = &s390_cpu_features[num];
> + switch (feature->type) {
> + case TYPE_HWCAP:
> + return !!(elf_hwcap & (1UL << feature->num));
Before somebody else mentions it, I could have done better. Nowadays
this should be:
return !!(elf_hwcap & BIT(feature->num));
next prev parent reply other threads:[~2022-07-12 19:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-12 10:52 [PATCH 0/3] s390/cpufeature: rework to allow different types of cpufeatures Steffen Eiden
2022-07-12 10:52 ` [PATCH 1/3] s390/cpufeature: rework to allow more than only hwcap bits Steffen Eiden
2022-07-12 11:56 ` Steffen Eiden
2022-07-12 16:46 ` Claudio Imbrenda
2022-07-12 19:27 ` Heiko Carstens
2022-07-12 19:25 ` Heiko Carstens [this message]
2022-07-13 8:32 ` Steffen Eiden
2022-07-14 10:52 ` Heiko Carstens
2022-07-15 8:03 ` Hendrik Brueckner
2022-07-12 10:52 ` [PATCH 2/3] s390/cpufeature: allow for facility bits Steffen Eiden
2022-07-12 16:50 ` Claudio Imbrenda
2022-07-12 10:52 ` [PATCH 3/3] s390/uvdevice: autoload module based on CPU facility Steffen Eiden
2022-07-12 16:49 ` Claudio Imbrenda
2022-07-13 8:39 ` Steffen Eiden
2022-07-13 9:16 ` Claudio Imbrenda
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=Ys3Kt7nG2jtE8H3H@osiris \
--to=hca@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=frankja@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=nrb@linux.ibm.com \
--cc=seiden@linux.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.