* [PATCH v2 3/4] cpufreq: Remove driver default policy->min/max init
From: Pierre Gondois @ 2026-05-11 13:55 UTC (permalink / raw)
To: linux-kernel
Cc: Jie Zhan, Lifeng Zheng, Ionela Voinescu, Sumit Gupta,
Zhongqiu Han, Pierre Gondois, Rafael J. Wysocki, Viresh Kumar,
Jonathan Corbet, Shuah Khan, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, Srinivas Pandruvada, Len Brown,
Saravana Kannan, linux-pm, linux-doc
In-Reply-To: <20260511135538.522653-1-pierre.gondois@arm.com>
Prior to [1], drivers were setting policy->min/max and
the value was used as a QoS constraint. After that change,
the values were only temporarily used: cpufreq_set_policy()
ultimately overriding them through:
cpufreq_policy_online()
\-cpufreq_init_policy()
\-cpufreq_set_policy()
\-/* Set policy->min/max */
This patch reinstate the initial behaviour. This will allow
drivers to request min/max QoS frequencies if desired.
For instance, the cppc driver advertises a lowest non-linear
frequency, which should be used as a min QoS value.
To avoid having drivers setting policy->min/max to default
values which are considered as QoS values (i.e. the reason
why [1] was introduced), remove the initialization of
policy->min/max in .init() callbacks wherever the
policy->min/max values are identical to the
policy->cpuinfo.min/max_freq.
Indeed, the previous patch ("cpufreq: Set default
policy->min/max values for all drivers") makes this initialization
redundant.
The only drivers where these values are different are:
- gx-suspmod.c (min)
- cppc-cpufreq.c (min)
- longrun.c
[1]
commit 521223d8b3ec ("cpufreq: Fix initialization of min and
max frequency QoS requests")
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
---
drivers/cpufreq/amd-pstate.c | 14 ++++++--------
drivers/cpufreq/cppc_cpufreq.c | 5 ++---
drivers/cpufreq/cpufreq-nforce2.c | 4 ++--
drivers/cpufreq/freq_table.c | 7 +++----
drivers/cpufreq/gx-suspmod.c | 2 +-
drivers/cpufreq/intel_pstate.c | 3 ---
drivers/cpufreq/pcc-cpufreq.c | 10 ++++------
drivers/cpufreq/pxa3xx-cpufreq.c | 5 ++---
drivers/cpufreq/sh-cpufreq.c | 6 ++----
drivers/cpufreq/virtual-cpufreq.c | 5 +----
10 files changed, 23 insertions(+), 38 deletions(-)
diff --git a/drivers/cpufreq/amd-pstate.c b/drivers/cpufreq/amd-pstate.c
index 453084c67327f..ecc3779e047d5 100644
--- a/drivers/cpufreq/amd-pstate.c
+++ b/drivers/cpufreq/amd-pstate.c
@@ -1090,10 +1090,9 @@ static int amd_pstate_cpu_init(struct cpufreq_policy *policy)
perf = READ_ONCE(cpudata->perf);
- policy->cpuinfo.min_freq = policy->min = perf_to_freq(perf,
- cpudata->nominal_freq,
- perf.lowest_perf);
- policy->cpuinfo.max_freq = policy->max = cpudata->max_freq;
+ policy->cpuinfo.min_freq = perf_to_freq(perf, cpudata->nominal_freq,
+ perf.lowest_perf);
+ policy->cpuinfo.max_freq = cpudata->max_freq;
policy->driver_data = cpudata;
ret = amd_pstate_cppc_enable(policy);
@@ -1907,10 +1906,9 @@ static int amd_pstate_epp_cpu_init(struct cpufreq_policy *policy)
perf = READ_ONCE(cpudata->perf);
- policy->cpuinfo.min_freq = policy->min = perf_to_freq(perf,
- cpudata->nominal_freq,
- perf.lowest_perf);
- policy->cpuinfo.max_freq = policy->max = cpudata->max_freq;
+ policy->cpuinfo.min_freq = perf_to_freq(perf, cpudata->nominal_freq,
+ perf.lowest_perf);
+ policy->cpuinfo.max_freq = cpudata->max_freq;
policy->driver_data = cpudata;
ret = amd_pstate_cppc_enable(policy);
diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index 7e7f9dfb7a24c..5abac50df7508 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -660,8 +660,6 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
* Section 8.4.7.1.1.5 of ACPI 6.1 spec)
*/
policy->min = cppc_perf_to_khz(caps, caps->lowest_nonlinear_perf);
- policy->max = cppc_perf_to_khz(caps, policy->boost_enabled ?
- caps->highest_perf : caps->nominal_perf);
/*
* Set cpuinfo.min_freq to Lowest to make the full range of performance
@@ -669,7 +667,8 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
* nonlinear perf
*/
policy->cpuinfo.min_freq = cppc_perf_to_khz(caps, caps->lowest_perf);
- policy->cpuinfo.max_freq = policy->max;
+ policy->cpuinfo.max_freq = cppc_perf_to_khz(caps, policy->boost_enabled ?
+ caps->highest_perf : caps->nominal_perf);
policy->transition_delay_us = cppc_cpufreq_get_transition_delay_us(cpu);
policy->shared_type = cpu_data->shared_type;
diff --git a/drivers/cpufreq/cpufreq-nforce2.c b/drivers/cpufreq/cpufreq-nforce2.c
index fbbbe501cf2dc..831102522ad64 100644
--- a/drivers/cpufreq/cpufreq-nforce2.c
+++ b/drivers/cpufreq/cpufreq-nforce2.c
@@ -355,8 +355,8 @@ static int nforce2_cpu_init(struct cpufreq_policy *policy)
min_fsb = NFORCE2_MIN_FSB;
/* cpuinfo and default policy values */
- policy->min = policy->cpuinfo.min_freq = min_fsb * fid * 100;
- policy->max = policy->cpuinfo.max_freq = max_fsb * fid * 100;
+ policy->cpuinfo.min_freq = min_fsb * fid * 100;
+ policy->cpuinfo.max_freq = max_fsb * fid * 100;
return 0;
}
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index 5b364d8da4f92..ea994647abc88 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -49,16 +49,15 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
max_freq = freq;
}
- policy->min = policy->cpuinfo.min_freq = min_freq;
- policy->max = max_freq;
+ policy->cpuinfo.min_freq = min_freq;
/*
* If the driver has set its own cpuinfo.max_freq above max_freq, leave
* it as is.
*/
if (policy->cpuinfo.max_freq < max_freq)
- policy->max = policy->cpuinfo.max_freq = max_freq;
+ policy->cpuinfo.max_freq = max_freq;
- if (policy->min == ~0)
+ if (min_freq == ~0)
return -EINVAL;
else
return 0;
diff --git a/drivers/cpufreq/gx-suspmod.c b/drivers/cpufreq/gx-suspmod.c
index d269a4f26f98e..d40c9e0bbb740 100644
--- a/drivers/cpufreq/gx-suspmod.c
+++ b/drivers/cpufreq/gx-suspmod.c
@@ -421,7 +421,7 @@ static int cpufreq_gx_cpu_init(struct cpufreq_policy *policy)
policy->min = maxfreq / max_duration;
else
policy->min = maxfreq / POLICY_MIN_DIV;
- policy->max = maxfreq;
+
policy->cpuinfo.min_freq = maxfreq / max_duration;
policy->cpuinfo.max_freq = maxfreq;
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 1292da53e5fcb..68ccc6eb1ef30 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -3049,9 +3049,6 @@ static int __intel_pstate_cpu_init(struct cpufreq_policy *policy)
policy->cpuinfo.max_freq = READ_ONCE(global.no_turbo) ?
cpu->pstate.max_freq : cpu->pstate.turbo_freq;
- policy->min = policy->cpuinfo.min_freq;
- policy->max = policy->cpuinfo.max_freq;
-
intel_pstate_init_acpi_perf_limits(policy);
policy->fast_switch_possible = true;
diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index ac2e90a65f0c4..0f185a13577f8 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -551,13 +551,11 @@ static int pcc_cpufreq_cpu_init(struct cpufreq_policy *policy)
goto out;
}
- policy->max = policy->cpuinfo.max_freq =
- ioread32(&pcch_hdr->nominal) * 1000;
- policy->min = policy->cpuinfo.min_freq =
- ioread32(&pcch_hdr->minimum_frequency) * 1000;
+ policy->cpuinfo.max_freq = ioread32(&pcch_hdr->nominal) * 1000;
+ policy->cpuinfo.min_freq = ioread32(&pcch_hdr->minimum_frequency) * 1000;
- pr_debug("init: policy->max is %d, policy->min is %d\n",
- policy->max, policy->min);
+ pr_debug("init: max_freq is %d, min_freq is %d\n",
+ policy->cpuinfo.max_freq, policy->cpuinfo.min_freq);
out:
return result;
}
diff --git a/drivers/cpufreq/pxa3xx-cpufreq.c b/drivers/cpufreq/pxa3xx-cpufreq.c
index 50ff3b6a69000..06b27cbc59d6a 100644
--- a/drivers/cpufreq/pxa3xx-cpufreq.c
+++ b/drivers/cpufreq/pxa3xx-cpufreq.c
@@ -185,9 +185,8 @@ static int pxa3xx_cpufreq_init(struct cpufreq_policy *policy)
int ret = -EINVAL;
/* set default policy and cpuinfo */
- policy->min = policy->cpuinfo.min_freq = 104000;
- policy->max = policy->cpuinfo.max_freq =
- (cpu_is_pxa320()) ? 806000 : 624000;
+ policy->cpuinfo.min_freq = 104000;
+ policy->cpuinfo.max_freq = (cpu_is_pxa320()) ? 806000 : 624000;
policy->cpuinfo.transition_latency = 1000; /* FIXME: 1 ms, assumed */
if (cpu_is_pxa300() || cpu_is_pxa310())
diff --git a/drivers/cpufreq/sh-cpufreq.c b/drivers/cpufreq/sh-cpufreq.c
index 642ddb9ea217e..3c99d7009cbe2 100644
--- a/drivers/cpufreq/sh-cpufreq.c
+++ b/drivers/cpufreq/sh-cpufreq.c
@@ -124,10 +124,8 @@ static int sh_cpufreq_cpu_init(struct cpufreq_policy *policy)
dev_notice(dev, "no frequency table found, falling back "
"to rate rounding.\n");
- policy->min = policy->cpuinfo.min_freq =
- (clk_round_rate(cpuclk, 1) + 500) / 1000;
- policy->max = policy->cpuinfo.max_freq =
- (clk_round_rate(cpuclk, ~0UL) + 500) / 1000;
+ policy->cpuinfo.min_freq = (clk_round_rate(cpuclk, 1) + 500) / 1000;
+ policy->cpuinfo.max_freq = (clk_round_rate(cpuclk, ~0UL) + 500) / 1000;
}
return 0;
diff --git a/drivers/cpufreq/virtual-cpufreq.c b/drivers/cpufreq/virtual-cpufreq.c
index 4159f31349b16..dc78b74409af4 100644
--- a/drivers/cpufreq/virtual-cpufreq.c
+++ b/drivers/cpufreq/virtual-cpufreq.c
@@ -164,10 +164,7 @@ static int virt_cpufreq_get_freq_info(struct cpufreq_policy *policy)
policy->cpuinfo.min_freq = 1;
policy->cpuinfo.max_freq = virt_cpufreq_get_perftbl_entry(policy->cpu, 0);
- policy->min = policy->cpuinfo.min_freq;
- policy->max = policy->cpuinfo.max_freq;
-
- policy->cur = policy->max;
+ policy->cur = policy->cpuinfo.max_freq;
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/4] cpufreq: Set default policy->min/max values for all drivers
From: Pierre Gondois @ 2026-05-11 13:55 UTC (permalink / raw)
To: linux-kernel
Cc: Jie Zhan, Lifeng Zheng, Ionela Voinescu, Sumit Gupta,
Zhongqiu Han, Pierre Gondois, Rafael J. Wysocki, Viresh Kumar,
Jonathan Corbet, Shuah Khan, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, Srinivas Pandruvada, Len Brown,
Saravana Kannan, linux-pm, linux-doc
In-Reply-To: <20260511135538.522653-1-pierre.gondois@arm.com>
Some drivers set policy->min/max in their .init() callback.
cpufreq_set_policy() will ultimately override them through:
cpufreq_policy_online()
\-cpufreq_init_policy()
\-cpufreq_set_policy()
\-/* Set policy->min/max */
Thus the policy min/max values provided are only temporary.
There is an exception if CPUFREQ_NEED_INITIAL_FREQ_CHECK is set and:
cpufreq_policy_online()
\-__cpufreq_driver_target()
\-cpufreq_driver->target()
To prepare for a following patch that will remove all
policy->min/max initialization in the driver .init() callback
if the min/max value is equal to the cpuinfo.min/max_freq,
set a default policy->min/max value for all drivers.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
---
drivers/cpufreq/cpufreq.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 034603c2af325..9e2d9d3fc5351 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1401,6 +1401,13 @@ static int cpufreq_policy_init_qos(struct cpufreq_policy *policy)
{
int ret;
+ /*
+ * If the driver didn't set policy->min/max, set them as
+ * they are used to clamp frequency requests.
+ */
+ policy->min = policy->min ? policy->min : policy->cpuinfo.min_freq;
+ policy->max = policy->max ? policy->max : policy->cpuinfo.max_freq;
+
if (policy->boost_supported) {
ret = freq_qos_add_request(&policy->constraints,
&policy->boost_freq_req,
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/4] cpufreq: Extract cpufreq_policy_init_qos() function
From: Pierre Gondois @ 2026-05-11 13:55 UTC (permalink / raw)
To: linux-kernel
Cc: Jie Zhan, Lifeng Zheng, Ionela Voinescu, Sumit Gupta,
Zhongqiu Han, Pierre Gondois, Rafael J. Wysocki, Viresh Kumar,
Jonathan Corbet, Shuah Khan, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, Srinivas Pandruvada, Len Brown,
Saravana Kannan, linux-pm, linux-doc
In-Reply-To: <20260511135538.522653-1-pierre.gondois@arm.com>
Extract the QoS related logic from cpufreq_policy_online()
to make the function shorter/simpler.
The logic is placed in cpufreq_policy_init_qos() and is
now executed right after the following calls:
- cpufreq_driver->init()
- cpufreq_table_validate_and_sort()
This helps preparing following patches that will,
in cpufreq_policy_init_qos():
- treat the policy->min/max values set by drivers as QoS requests.
- set a default policy->min/max value to all policies.
No functional change.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
---
drivers/cpufreq/cpufreq.c | 53 +++++++++++++++++++++++----------------
1 file changed, 32 insertions(+), 21 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 44eb1b7e7fc1b..034603c2af325 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1397,6 +1397,32 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
kfree(policy);
}
+static int cpufreq_policy_init_qos(struct cpufreq_policy *policy)
+{
+ int ret;
+
+ if (policy->boost_supported) {
+ ret = freq_qos_add_request(&policy->constraints,
+ &policy->boost_freq_req,
+ FREQ_QOS_MAX,
+ policy->cpuinfo.max_freq);
+ if (ret < 0)
+ return ret;
+ }
+
+ ret = freq_qos_add_request(&policy->constraints, &policy->min_freq_req,
+ FREQ_QOS_MIN, FREQ_QOS_MIN_DEFAULT_VALUE);
+ if (ret < 0)
+ return ret;
+
+ ret = freq_qos_add_request(&policy->constraints, &policy->max_freq_req,
+ FREQ_QOS_MAX, FREQ_QOS_MAX_DEFAULT_VALUE);
+ if (ret < 0)
+ return ret;
+
+ return ret;
+}
+
static int cpufreq_policy_online(struct cpufreq_policy *policy,
unsigned int cpu, bool new_policy)
{
@@ -1442,6 +1468,12 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
if (ret)
goto out_offline_policy;
+ if (new_policy) {
+ ret = cpufreq_policy_init_qos(policy);
+ if (ret < 0)
+ goto out_offline_policy;
+ }
+
/* related_cpus should at least include policy->cpus. */
cpumask_copy(policy->related_cpus, policy->cpus);
}
@@ -1458,27 +1490,6 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
add_cpu_dev_symlink(policy, j, get_cpu_device(j));
}
- if (policy->boost_supported) {
- ret = freq_qos_add_request(&policy->constraints,
- &policy->boost_freq_req,
- FREQ_QOS_MAX,
- policy->cpuinfo.max_freq);
- if (ret < 0)
- goto out_destroy_policy;
- }
-
- ret = freq_qos_add_request(&policy->constraints,
- &policy->min_freq_req, FREQ_QOS_MIN,
- FREQ_QOS_MIN_DEFAULT_VALUE);
- if (ret < 0)
- goto out_destroy_policy;
-
- ret = freq_qos_add_request(&policy->constraints,
- &policy->max_freq_req, FREQ_QOS_MAX,
- FREQ_QOS_MAX_DEFAULT_VALUE);
- if (ret < 0)
- goto out_destroy_policy;
-
blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
CPUFREQ_CREATE_POLICY, policy);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/4] cpufreq: Set policy->min and max as real QoS constraints
From: Pierre Gondois @ 2026-05-11 13:55 UTC (permalink / raw)
To: linux-kernel
Cc: Jie Zhan, Lifeng Zheng, Ionela Voinescu, Sumit Gupta,
Zhongqiu Han, Pierre Gondois, Rafael J. Wysocki, Viresh Kumar,
Jonathan Corbet, Shuah Khan, Huang Rui, Mario Limonciello,
Perry Yuan, K Prateek Nayak, Srinivas Pandruvada, Len Brown,
Saravana Kannan, linux-pm, linux-doc
This patch is a follow-up from the serie:
- [PATCH v6 0/4] cpufreq: Introduce boost frequency QoS
https://lore.kernel.org/lkml/20260317101753.2284763-1-pierre.gondois@arm.com/
v2:
- Split the patch in multiple steps
- Replace min/max -> min_freq/max_freq
- Add references to commit 521223d8b3ec ("cpufreq: Fix initialization
of min and max frequency QoS requests") to explain the intent
of the patch
- Update documentation (cpu-drivers.rst)
- Set default policy->min/max values before the call to
blocking_notifier_call_chain()
- Create a new cpufreq_policy_init_qos() function to put all
the QoS and policy->min/max logic inside.
- Didn't add Sumit's reviewed-by as the patches changed a bit.
v1:
https://lore.kernel.org/lkml/20260423084731.1090384-1-pierre.gondois@arm.com/#t
Pierre Gondois (4):
cpufreq: Extract cpufreq_policy_init_qos() function
cpufreq: Set default policy->min/max values for all drivers
cpufreq: Remove driver default policy->min/max init
cpufreq: Use policy->min/max init as QoS request
Documentation/cpu-freq/cpu-drivers.rst | 10 +++-
drivers/cpufreq/amd-pstate.c | 14 +++---
drivers/cpufreq/cppc_cpufreq.c | 5 +-
drivers/cpufreq/cpufreq-nforce2.c | 4 +-
drivers/cpufreq/cpufreq.c | 68 ++++++++++++++++++--------
drivers/cpufreq/freq_table.c | 7 ++-
drivers/cpufreq/gx-suspmod.c | 2 +-
drivers/cpufreq/intel_pstate.c | 3 --
drivers/cpufreq/pcc-cpufreq.c | 10 ++--
drivers/cpufreq/pxa3xx-cpufreq.c | 5 +-
drivers/cpufreq/sh-cpufreq.c | 6 +--
drivers/cpufreq/virtual-cpufreq.c | 5 +-
12 files changed, 78 insertions(+), 61 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Michal Hocko @ 2026-05-11 13:49 UTC (permalink / raw)
To: Sasha Levin
Cc: Breno Leitao, Andrew Morton, corbet, skhan, linux-doc,
linux-kernel, linux-kselftest, gregkh
In-Reply-To: <agHcFCRVSn5ra5Kc@laps>
On Mon 11-05-26 09:39:32, Sasha Levin wrote:
> On Mon, May 11, 2026 at 03:07:51PM +0200, Michal Hocko wrote:
> > On Mon 11-05-26 04:41:38, Breno Leitao wrote:
> > > On Fri, May 08, 2026 at 05:47:04PM -0400, Sasha Levin wrote:
> > > > On Fri, May 08, 2026 at 01:56:30PM -0700, Andrew Morton wrote:
> > > > > On Thu, 7 May 2026 03:05:45 -0400 Sasha Levin <sashal@kernel.org> wrote:
> > > > >
> > > > > > When a (security) issue goes public, fleets stay exposed until a patched kernel
> > > > > > is built, distributed, and rebooted into.
> > > > > >
> > > > > > For many such issues the simplest mitigation is to stop calling the buggy
> > > > > > function. Killswitch provides that. An admin writes:
> > > > > >
> > > > > > echo "engage af_alg_sendmsg -1" \
> > > > > > > /sys/kernel/security/killswitch/control
> > > > >
> > > > > It certainly sounds useful, but what would I know. How do we hunt down
> > > > > suitable operations people (aka "target audience") to find out how
> > > > > useful this is to them?
> > > >
> > > > I'm not entierly sure here... If folks have suggestions on folks to loop in,
> > > > that'll be great!
> > >
> > > I work with these issues at Meta, and this approach would address a real
> > > need we have.
>
> Thanks for the feedback!
>
> > > While livepatch could theoretically solve this problem, it's less suited
> > > for rapid mitigation for a couple of reasons:
> > >
> > > 1) Livepatch rollout is inherently slower due to the blast radius if a
> > > bug exists in the livepatch mechanism itself.
> > >
> > > 2) It's common to run hundreds of different kernel versions across a
> > > fleet. Since livepatch is kernel-specific, a single CVE suddenly
> > > requires building and deploying hundreds of individual livepatches—
> > > far less practical than a simple sysfs write.
> >
> > LP is certainly a more laborous solution. I guess this is quite clear.
> > It is also much safer option as it deals with all implementation details
> > like consistency. All that is not done for fun. I am really wondering
> > how admins are expected to a) know which kernel functions are ok/safe to
> > disable and b) when it is safe to do so without introducing unsafe
> > kernel state or introduce an outright bug that way.
>
> In a similar way to how they would know if a given livepatch is safe to apply -
> ideally it would be communicated by the vendor/distro/kernel team.
You have missed my point. KLP takes an extra steps to make sure patching
a particular function is safe to modify or to put the change into the
effect.
> "On Debian XX.YY, use the following command to mitigate CVE-AAAA-BBBB:
>
> echo "engage woops -1" > /sys/kernel/security/killswitch/control"
>
> > Thiking about this I can see how waiting for an official LP can be time
> > consuming and sometimes creating those is far from trivial. But would it
> > make sense to have automated LP creation tooling available that would
> > allow to return early from a function and relly on the existing
> > infrastructure to do the right thing?
>
> This would definitely help (and in light of how the last couple of weeks played
> out, the case for livepatches definitely increased), but not all
> vendors/distros provide livepatches.
The point I've tried to make is that you (as an admin) shouldn't depend
on your vendor to provide you with an official LP just to disable a
certain function(ality). That is/should be a trivial case where the LP
should be ideally generated automagically if you have a tooling
available. I might be wrong and overlook some complexity here.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] cpufreq: CPPC: add autonomous mode boot parameter support
From: Sumit Gupta @ 2026-05-11 13:42 UTC (permalink / raw)
To: Jie Zhan, rafael, viresh.kumar, pierre.gondois, ionela.voinescu,
zhenglifeng1, corbet, skhan, rdunlap, mario.limonciello, linux-pm,
linux-doc, linux-kernel
Cc: linux-tegra, treding, jonathanh, vsethi, ksitaraman, sanjayc,
mochs, bbasu, sumitg
In-Reply-To: <a9324a65-9da9-4e35-8c78-a054fb24bc8d@hisilicon.com>
On 08/05/26 08:03, Jie Zhan wrote:
> External email: Use caution opening links or attachments
>
>
> On 5/5/2026 8:29 PM, Sumit Gupta wrote:
>> Hi Jie,
>>
>>
>> On 27/04/26 13:54, Jie Zhan wrote:
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> Hi Sumit,
>>>
>>> In general, I would expect this parameter only toggles on auto_sel by
>>> default. IIUC, other CPPC configurations (min/max/desired perf, EPP,
>>> enable) are optional and not closely related to this.
>>>
>>> Why including those stuff here?
>>>
>>>
>>> Please see other questions inline.
>>>
>>> Thanks!
>>> Jie
>> These together provide a known, predictable autonomous mode boot.
>> min/max/desired seeding ensures HW has a known starting bound (BIOS
>> may leave them unset).
>> EPP=PERFORMANCE_PREF is needed as BIOS defaults often bias toward
>> energy saving, and admins on many CPU systems shouldn't have to script
>> per CPU sysfs writes at every boot to undo that.
> Hi Sumit,
>
> The min/max/desired perf might be a slightly different case, but the EPP
> value should probably follow the default if there is?
> Otherwise, users may complain that their BIOS defaults don't work and find
> out it's driver's fault.
>
> Alternatively, we may also make an assumption that we ignore BIOS EPP
> config, but not sure if that's suitable?
>
> (Perhaps let's just discuss in the bottom trunk because the main issue is
> pretty much the same.)
>>> On 4/25/2026 4:18 AM, Sumit Gupta wrote:
>>>> Add a kernel boot parameter 'cppc_cpufreq.auto_sel_mode' to enable
>>>> CPPC autonomous performance selection on all CPUs at system startup.
>>>> When autonomous mode is enabled, the hardware automatically adjusts
>>>> CPU performance based on workload demands using Energy Performance
>>>> Preference (EPP) hints.
>>>>
>>>> When auto_sel_mode=1:
>>>> - Configure all CPUs for autonomous operation on first init
>>>> - Set EPP to performance preference (0x0)
>>>> - Use HW min/max_perf when available; otherwise initialize from caps
>>>> - Clamp desired_perf to bounds before enabling autonomous mode
>>>> - Hardware controls frequency instead of the OS governor
>>>>
>>>> The boot parameter is applied only during first policy initialization.
>>>> Skip applying it on CPU hotplug to preserve runtime sysfs configuration.
>>>>
>>>> This patch depends on patch [2] ("cpufreq: Set policy->min and max
>>>> as real QoS constraints") so that the policy->min/max set in
>>>> cppc_cpufreq_cpu_init() are not overridden by cpufreq_set_policy()
>>>> during init.
>>>>
>>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> (Documentation)
>>>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>>>> ---
>>>> v[1] -> v2:
>>>> - Call cppc_set_enable() unconditionally so CPPC is enabled for both
>>>> OS-driven and autonomous modes.
>>> Why adding this in v2?
>>> This looks like a separate issue since setting CPPC Enable reg doesn't seem
>>> to be related with autonomous control.
>> In v2, moved it out of the auto_sel specific check.
>> Agree that cppc_set_enable() is general CPPC enablement and can be split
>> into a separate patch in v3 if preferred.
>>
> Yeah it should be a separate patch I think.
>>>> - Init min/max from caps instead of cppc_cpufreq_update_perf_limits()
>>>> as policy->min/max aren't yet populated.
>>>>
>>>> [1] https://lore.kernel.org/lkml/20260317151053.2361475-1-sumitg@nvidia.com/
>>>> [2] https://lore.kernel.org/lkml/20260423084731.1090384-2-pierre.gondois@arm.com/
>>>> ---
>>>> .../admin-guide/kernel-parameters.txt | 13 +++
>>>> drivers/cpufreq/cppc_cpufreq.c | 89 +++++++++++++++++--
>>>> 2 files changed, 97 insertions(+), 5 deletions(-)
>>>>
> ...
>>>> +
>>>> + policy->cur = cppc_perf_to_khz(caps,
>>>> + cpu_data->perf_ctrls.desired_perf);
>>>> +
>>>> + /* EPP is optional - some platforms may not support it */
>>>> + ret = cppc_set_epp(cpu, CPPC_EPP_PERFORMANCE_PREF);
>>> Why setting this to PERFORMANCE by default?
>>> A platform can have its own default EPP value. This would override that.
>> The boot option targets performance oriented use cases on many CPU
>> systems, avoiding sysfs scripting across all CPUs on every boot.
>> The BIOS default EPP (often biased toward energy saving) would otherwise
>> steer HW away from that goal. Admins can still re-tune EPP at runtime via
>> the existing energy_performance_preference_val sysfs.
>>
> Yeah, avoiding scripting makes sense for sure.
> The thing is how do we do this nicely.
>
> For now we need to consider follow either the BIOS default or the driver
> default.
> They seem to be exclusive since there isn't a clear way to support both at
> the same time.
>
> So, are we going to support the BIOS default case?
> For example, users can config a default EPP in the BIOS setup menu.
To consider the BIOS default case, we can extend the parameter to accept
an EPP mode in v3:
- cppc_cpufreq.auto_sel_mode=performance / =1 (EPP=performance)
- cppc_cpufreq.auto_sel_mode=default / =2 (preserve BIOS EPP)
Thank you,
Sumit Gupta
....
^ permalink raw reply
* Re: [PATCH v2] killswitch: add per-function short-circuit mitigation primitive
From: Sasha Levin @ 2026-05-11 13:41 UTC (permalink / raw)
To: Breno Leitao
Cc: corbet, akpm, skhan, linux-doc, linux-kernel, linux-kselftest,
gregkh
In-Reply-To: <agHSFo0yqypa9vk9@gmail.com>
On Mon, May 11, 2026 at 06:14:27AM -0700, Breno Leitao wrote:
>helo Sasha,
>
>First of all, Thanks for this feature, this is useful to me, and I am
>interested in it. Feel free to copy me and I can test the next revisions
>
>On Fri, May 08, 2026 at 03:57:48PM -0400, Sasha Levin wrote:
>
>> +config KILLSWITCH
>> + bool "Killswitch: short-circuit a kernel function as a CVE mitigation"
>> + depends on SECURITYFS
>> + depends on KPROBES && HAVE_KPROBES_ON_FTRACE
>> + depends on HAVE_FUNCTION_ERROR_INJECTION
>> + select FUNCTION_ERROR_INJECTION
>> + help
>> + Provide an admin-facing mechanism to make a chosen kernel function
>> + return a fixed value without executing its body, as a temporary
>> + mitigation for a security bug before a real fix is available.
>> +
>> + Operators write "engage <symbol> <retval> [reason]" to
>
>Should [reason] be shown at "engaged" ? I was expecting it, and in fact find it
>very useful, but I don't see it.
>
> # echo "engage __x64_sys_getuid 12 CVE-2026-99999-INCIDENT-4242" > /sys/kernel/security/killswitch/control
> # cat /sys/kernel/security/killswitch/engaged
> __x64_sys_getuid retval=12 hits=12
This was a woopsie on my end: originally I planned to have a reason field, but
then decided to drop it to keep the patch simple. However, I forgot to fix up
the kconfig help text :(
If you think it'll be useful, I'm happy to add it back.
>> +#if IS_ENABLED(CONFIG_KUNIT)
>> +#include <kunit/test.h>
>> +
>> +/* Non-static so kallsyms resolves them without CONFIG_KALLSYMS_ALL. */
>> +int ks_kunit_target_int(int x);
>> +void *ks_kunit_target_ptr(int x);
>> +
>> +/* noipa keeps the call out-of-line and uneliminated. */
>> +__attribute__((__noipa__)) int ks_kunit_target_int(int x)
>> +{
>> + return x + 1;
>> +}
>> +
>> +__attribute__((__noipa__)) void *ks_kunit_target_ptr(int x)
>> +{
>> + return ERR_PTR(-EIO);
>> +}
>
>When compiling with LLVM=1, I get the following error:
>
> kernel/killswitch.c:708:16: error: unknown attribute '__noipa__' ignored [-Werror,-Wunknown-attributes]
> 708 | __attribute__((__noipa__)) int ks_kunit_target_int(int x)
> | ^~~~~~~~~
> kernel/killswitch.c:713:16: error: unknown attribute '__noipa__' ignored [-Werror,-Wunknown-attributes]
> 713 | __attribute__((__noipa__)) void *ks_kunit_target_ptr(int x)
> | ^~~~~~~~~
Will fix, thanks!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Breno Leitao @ 2026-05-11 13:40 UTC (permalink / raw)
To: Michal Hocko
Cc: Sasha Levin, Andrew Morton, corbet, skhan, linux-doc,
linux-kernel, linux-kselftest, gregkh, ivaz
In-Reply-To: <agHUp8ulaWJ75WU5@tiehlicka>
Hello Michal,
On Mon, May 11, 2026 at 03:07:51PM +0200, Michal Hocko wrote:
> > I work with these issues at Meta, and this approach would address a real
> > need we have.
> >
> > While livepatch could theoretically solve this problem, it's less suited
> > for rapid mitigation for a couple of reasons:
> >
> > 1) Livepatch rollout is inherently slower due to the blast radius if a
> > bug exists in the livepatch mechanism itself.
> >
> > 2) It's common to run hundreds of different kernel versions across a
> > fleet. Since livepatch is kernel-specific, a single CVE suddenly
> > requires building and deploying hundreds of individual livepatches—
> > far less practical than a simple sysfs write.
>
> LP is certainly a more laborous solution. I guess this is quite clear.
>
> It is also much safer option as it deals with all implementation details
> like consistency. All that is not done for fun. I am really wondering
> how admins are expected to a) know which kernel functions are ok/safe to
> disable and b) when it is safe to do so without introducing unsafe
> kernel state or introduce an outright bug that way.
You raise a valid concern. There's no simple answer. Making these decisions
requires deep understanding of both the code and the potential consequences.
The value proposition here (IMO) is the ability to completely disable a
code path by returning an error code (such as -EINVAL or -EBUSY) at key
entry points, rather than attempting surgical modifications.
While this approach is far from perfect, it can serve as an effective
stopgap measure until a proper fix is deployed or a livepatch becomes
available.
> Thiking about this I can see how waiting for an official LP can be time
> consuming and sometimes creating those is far from trivial. But would it
> make sense to have automated LP creation tooling available that would
> allow to return early from a function and relly on the existing
> infrastructure to do the right thing?
Absolutely. I view this as a progression of mitigation strategies, where
the ultimate goal is deploying a properly fixed kernel, but reaching that
endpoint may require intermediate steps.
1) Fix and deploy a new kernel:
* Pros: Lowest risk, permanent solution
* Cons:
- Requires reboot and extended downtime
2) Livepatch:
* Pros: Complete mitigation, clean approach, zero downtime
* Cons:
- Time-intensive rollout (requires bake time and health checks)
- Demands manual patch creation and review for each kernel version
(i.e., kernel developer involvement is essential)
3) This approach (killswitch):
* Pros: Immediate deployment capability
- Security engineers familiar with kernel code can act independently
* Cons:
- Risk of instability if the operator misjudges the impact
In short, I see killswitch as a complementary tool in the security
toolbox, not a universal solution.
--breno
^ permalink raw reply
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Sasha Levin @ 2026-05-11 13:39 UTC (permalink / raw)
To: Michal Hocko
Cc: Breno Leitao, Andrew Morton, corbet, skhan, linux-doc,
linux-kernel, linux-kselftest, gregkh
In-Reply-To: <agHUp8ulaWJ75WU5@tiehlicka>
On Mon, May 11, 2026 at 03:07:51PM +0200, Michal Hocko wrote:
>On Mon 11-05-26 04:41:38, Breno Leitao wrote:
>> On Fri, May 08, 2026 at 05:47:04PM -0400, Sasha Levin wrote:
>> > On Fri, May 08, 2026 at 01:56:30PM -0700, Andrew Morton wrote:
>> > > On Thu, 7 May 2026 03:05:45 -0400 Sasha Levin <sashal@kernel.org> wrote:
>> > >
>> > > > When a (security) issue goes public, fleets stay exposed until a patched kernel
>> > > > is built, distributed, and rebooted into.
>> > > >
>> > > > For many such issues the simplest mitigation is to stop calling the buggy
>> > > > function. Killswitch provides that. An admin writes:
>> > > >
>> > > > echo "engage af_alg_sendmsg -1" \
>> > > > > /sys/kernel/security/killswitch/control
>> > >
>> > > It certainly sounds useful, but what would I know. How do we hunt down
>> > > suitable operations people (aka "target audience") to find out how
>> > > useful this is to them?
>> >
>> > I'm not entierly sure here... If folks have suggestions on folks to loop in,
>> > that'll be great!
>>
>> I work with these issues at Meta, and this approach would address a real
>> need we have.
Thanks for the feedback!
>> While livepatch could theoretically solve this problem, it's less suited
>> for rapid mitigation for a couple of reasons:
>>
>> 1) Livepatch rollout is inherently slower due to the blast radius if a
>> bug exists in the livepatch mechanism itself.
>>
>> 2) It's common to run hundreds of different kernel versions across a
>> fleet. Since livepatch is kernel-specific, a single CVE suddenly
>> requires building and deploying hundreds of individual livepatches—
>> far less practical than a simple sysfs write.
>
>LP is certainly a more laborous solution. I guess this is quite clear.
>It is also much safer option as it deals with all implementation details
>like consistency. All that is not done for fun. I am really wondering
>how admins are expected to a) know which kernel functions are ok/safe to
>disable and b) when it is safe to do so without introducing unsafe
>kernel state or introduce an outright bug that way.
In a similar way to how they would know if a given livepatch is safe to apply -
ideally it would be communicated by the vendor/distro/kernel team.
"On Debian XX.YY, use the following command to mitigate CVE-AAAA-BBBB:
echo "engage woops -1" > /sys/kernel/security/killswitch/control"
>Thiking about this I can see how waiting for an official LP can be time
>consuming and sometimes creating those is far from trivial. But would it
>make sense to have automated LP creation tooling available that would
>allow to return early from a function and relly on the existing
>infrastructure to do the right thing?
This would definitely help (and in light of how the last couple of weeks played
out, the case for livepatches definitely increased), but not all
vendors/distros provide livepatches.
My personal usecase is simple: I use debian, with their kernel. I'm not going
to get livepatches from debian, and it would take a few days/weeks for a kernel
update to land. I want a simple solution that'll let me disable functionality I
don't care about.
So I can't use livepatching/fault injection/etc easily.
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH v2 10/10] riscv: hwprobe: Introduce rva23u64 base behavior
From: Guodong Xu @ 2026-05-12 1:34 UTC (permalink / raw)
To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner
Cc: Andrew Jones, Charlie Jenkins, Samuel Holland, linux-doc,
linux-riscv, linux-kernel, linux-kselftest, kvm, kvm-riscv,
Guodong Xu
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc@riscstar.com>
Provide a hwprobe base-behavior bit so userspace can check RVA23U64
support in one call. Without it, a consumer needs five hwprobe
calls and four prctl calls, which is error-prone to require of every
caller. Most software treats RVA23U64 as a new base anyway, so
expose it directly.
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2:
- Detect RVA23U64 by reading from the cached hart_isa[].isa_bases
bitmap populated by riscv_init_isa_bases() at init time, sharing
one source of truth with /proc/cpuinfo.
---
Documentation/arch/riscv/hwprobe.rst | 8 ++++++++
arch/riscv/include/uapi/asm/hwprobe.h | 3 ++-
arch/riscv/kernel/sys_hwprobe.c | 23 +++++++++++++++-------
tools/testing/selftests/riscv/hwprobe/which-cpus.c | 2 +-
4 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index cb31fd3b12017..9b901bf8bab9a 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -67,6 +67,14 @@ The following keys are defined:
programs (it may still be executed in userspace via a
kernel-controlled mechanism such as the vDSO).
+ * :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_RVA23U64`: Support for all mandatory
+ extensions of RVA23U64, as defined in the RISC-V Profiles specification
+ starting from commit 0273f3c921b6 ("rva23/rvb23 ratified").
+
+ The RVA23U64 base is based upon the IMA base and therefore IMA extension
+ keys (e.g. :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_0`:) may be used to probe
+ optional extensions.
+
* :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_0`: A bitmask containing extensions
that are compatible with the :c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`:
base system behavior.
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 430dc49a82863..d940ba4f6a1e8 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -21,7 +21,8 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_KEY_MARCHID 1
#define RISCV_HWPROBE_KEY_MIMPID 2
#define RISCV_HWPROBE_KEY_BASE_BEHAVIOR 3
-#define RISCV_HWPROBE_BASE_BEHAVIOR_IMA (1 << 0)
+#define RISCV_HWPROBE_BASE_BEHAVIOR_IMA (1 << 0)
+#define RISCV_HWPROBE_BASE_BEHAVIOR_RVA23U64 (1 << 1)
#define RISCV_HWPROBE_KEY_IMA_EXT_0 4
#define RISCV_HWPROBE_IMA_FD (1 << 0)
#define RISCV_HWPROBE_IMA_C (1 << 1)
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index dcc102bf8f183..c43fcad737b73 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -225,6 +225,17 @@ static bool hwprobe_ext0_has(const struct cpumask *cpus, u64 ext)
return (pair.value & ext);
}
+static bool hwprobe_has_isa_base(const struct cpumask *cpus, unsigned int base)
+{
+ int cpu;
+
+ for_each_cpu(cpu, cpus) {
+ if (!test_bit(base, hart_isa[cpu].isa_bases))
+ return false;
+ }
+ return true;
+}
+
#if defined(CONFIG_RISCV_PROBE_UNALIGNED_ACCESS)
static u64 hwprobe_misaligned(const struct cpumask *cpus)
{
@@ -307,14 +318,12 @@ static void hwprobe_one_pair(struct riscv_hwprobe *pair,
case RISCV_HWPROBE_KEY_MIMPID:
hwprobe_arch_id(pair, cpus);
break;
- /*
- * The kernel already assumes that the base single-letter ISA
- * extensions are supported on all harts, and only supports the
- * IMA base, so just cheat a bit here and tell that to
- * userspace.
- */
case RISCV_HWPROBE_KEY_BASE_BEHAVIOR:
- pair->value = RISCV_HWPROBE_BASE_BEHAVIOR_IMA;
+ pair->value = 0;
+ if (hwprobe_has_isa_base(cpus, RISCV_ISA_BASE_IMA))
+ pair->value |= RISCV_HWPROBE_BASE_BEHAVIOR_IMA;
+ if (hwprobe_has_isa_base(cpus, RISCV_ISA_BASE_RVA23U64))
+ pair->value |= RISCV_HWPROBE_BASE_BEHAVIOR_RVA23U64;
break;
case RISCV_HWPROBE_KEY_IMA_EXT_0:
diff --git a/tools/testing/selftests/riscv/hwprobe/which-cpus.c b/tools/testing/selftests/riscv/hwprobe/which-cpus.c
index 587feb198c049..f8c797b1d0fd9 100644
--- a/tools/testing/selftests/riscv/hwprobe/which-cpus.c
+++ b/tools/testing/selftests/riscv/hwprobe/which-cpus.c
@@ -105,7 +105,7 @@ int main(int argc, char **argv)
pairs[0] = (struct riscv_hwprobe){ .key = RISCV_HWPROBE_KEY_BASE_BEHAVIOR, };
rc = riscv_hwprobe(pairs, 1, 0, NULL, 0);
assert(rc == 0 && pairs[0].key == RISCV_HWPROBE_KEY_BASE_BEHAVIOR &&
- pairs[0].value == RISCV_HWPROBE_BASE_BEHAVIOR_IMA);
+ (pairs[0].value & RISCV_HWPROBE_BASE_BEHAVIOR_IMA));
pairs[0] = (struct riscv_hwprobe){ .key = RISCV_HWPROBE_KEY_IMA_EXT_0, };
rc = riscv_hwprobe(pairs, 1, 0, NULL, 0);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 09/10] riscv: cpu: Output isa bases lines in cpuinfo
From: Guodong Xu @ 2026-05-12 1:34 UTC (permalink / raw)
To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner
Cc: Andrew Jones, Charlie Jenkins, Samuel Holland, linux-doc,
linux-riscv, linux-kernel, linux-kselftest, kvm, kvm-riscv,
Guodong Xu
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc@riscstar.com>
Output two new lines per processor in /proc/cpuinfo:
isa bases : <bases that all harts conform to>
hart isa bases : <bases that this specific hart conforms to>
These read directly from the cached riscv_isa_bases and
hart_isa[cpu].isa_bases bitmaps populated at boot by
riscv_init_isa_bases().
Example output on qemu booted with -cpu rva23s64,sv39=on,pmp=on
(showing only the new lines plus their neighbors for context):
processor : 0
hart : 4
isa bases : rv64ima rva23u64
isa : rv64imafdcbvh_zicbom_zicbop_...
mmu : sv39
...
mimpid : 0x0
hart isa bases : rv64ima rva23u64
hart isa : rv64imafdcbvh_zicbom_zicbop_...
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2:
- Read from the cached riscv_isa_bases and hart_isa[cpu_id].isa_bases
bitmaps populated by riscv_init_isa_bases() at init time.
---
arch/riscv/kernel/cpu.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index 3dbc8cc557dd1..31e2857dcdcf1 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -305,6 +305,26 @@ static void print_mmu(struct seq_file *f)
seq_printf(f, "mmu\t\t: %s\n", sv_type);
}
+static const char * const riscv_isa_base_names[] = {
+#ifdef CONFIG_32BIT
+ [RISCV_ISA_BASE_IMA] = "rv32ima",
+#else
+ [RISCV_ISA_BASE_IMA] = "rv64ima",
+#endif
+ [RISCV_ISA_BASE_RVA23U64] = "rva23u64",
+};
+
+static void print_isa_bases(struct seq_file *m, const unsigned long *isa_bases)
+{
+ unsigned int i;
+
+ for (i = 0; i < RISCV_NR_ISA_BASES; i++) {
+ if (test_bit(i, isa_bases))
+ seq_printf(m, " %s", riscv_isa_base_names[i]);
+ }
+ seq_puts(m, "\n");
+}
+
static void *c_start(struct seq_file *m, loff_t *pos)
{
if (*pos == nr_cpu_ids)
@@ -336,6 +356,9 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, "processor\t: %lu\n", cpu_id);
seq_printf(m, "hart\t\t: %lu\n", cpuid_to_hartid_map(cpu_id));
+ seq_puts(m, "isa bases\t:");
+ print_isa_bases(m, riscv_isa_bases);
+
/*
* For historical raisins, the isa: line is limited to the lowest common
* denominator of extensions supported across all harts. A true list of
@@ -360,6 +383,9 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, "marchid\t\t: 0x%lx\n", ci->marchid);
seq_printf(m, "mimpid\t\t: 0x%lx\n", ci->mimpid);
+ seq_puts(m, "hart isa bases\t:");
+ print_isa_bases(m, hart_isa[cpu_id].isa_bases);
+
/*
* Print the ISA extensions specific to this hart, which may show
* additional extensions not present across all harts.
--
2.43.0
^ permalink raw reply related
* [PATCH v2 08/10] riscv: cpufeature: Introduce ISA bases bitmap and rva23u64 detection
From: Guodong Xu @ 2026-05-12 1:34 UTC (permalink / raw)
To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner
Cc: Andrew Jones, Charlie Jenkins, Samuel Holland, linux-doc,
linux-riscv, linux-kernel, linux-kselftest, kvm, kvm-riscv,
Guodong Xu
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc@riscstar.com>
Introduce a per-hart and host-wide bitmap of conformant ISA "bases" --
named profile-class sets such as IMA and RVA23U64 -- and compute
both at init time.
This is the cache that subsequent consumers (hwprobe's
RVA23U64 base behavior bit, /proc/cpuinfo's "isa bases" lines, etc.)
read without recomputing.
riscv_init_isa_bases() iterates over all possible cpus to populate
each hart_isa[cpu].isa_bases, then computes the host-wide
riscv_isa_bases against the AND-across-harts riscv_isa bitmap. It is
registered as a subsys_initcall so it executes after
core_initcall(tagged_addr_init), which probes senvcfg.PMM and
populates have_user_pmlen_*. Without that ordering,
riscv_have_user_pmlen(7) would still return its default false and the
RVA23U64 detection path would always bail.
The detection itself is encapsulated in riscv_set_isa_bases(), which
takes an output bases bitmap and an input ISA bitmap.
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2:
- Implement riscv_init_isa_bases() that runs at system init time,
after tagged_addr_init() populates have_user_pmlen_*.
- Split RVA23S64 placeholder into a future patch.
---
arch/riscv/include/asm/cpufeature.h | 14 ++++++
arch/riscv/kernel/cpufeature.c | 92 +++++++++++++++++++++++++++++++++++++
2 files changed, 106 insertions(+)
diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h
index 739fcc84bf7b2..facc31b2960c6 100644
--- a/arch/riscv/include/asm/cpufeature.h
+++ b/arch/riscv/include/asm/cpufeature.h
@@ -25,10 +25,24 @@ struct riscv_cpuinfo {
unsigned long mimpid;
};
+enum {
+ RISCV_ISA_BASE_IMA,
+ RISCV_ISA_BASE_RVA23U64,
+ RISCV_NR_ISA_BASES,
+};
+
+/**
+ * struct riscv_isainfo - per-hart ISA state
+ * @isa: bitmap of ISA extensions this hart implements
+ * @isa_bases: bitmap of profile bases this hart conforms to
+ */
struct riscv_isainfo {
DECLARE_BITMAP(isa, RISCV_ISA_EXT_MAX);
+ DECLARE_BITMAP(isa_bases, RISCV_NR_ISA_BASES);
};
+extern unsigned long riscv_isa_bases[BITS_TO_LONGS(RISCV_NR_ISA_BASES)];
+
DECLARE_PER_CPU(struct riscv_cpuinfo, riscv_cpuinfo);
extern const struct seq_operations cpuinfo_op;
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 81145621dc378..6e8dd33aa3888 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -41,6 +41,9 @@ unsigned long elf_hwcap __read_mostly;
/* Host ISA bitmap */
static DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX) __read_mostly;
+/* Host ISA bases bitmap */
+DECLARE_BITMAP(riscv_isa_bases, RISCV_NR_ISA_BASES) __read_mostly;
+
/* Per-cpu ISA extensions. */
struct riscv_isainfo hart_isa[NR_CPUS];
@@ -1305,3 +1308,92 @@ void __init_or_module riscv_cpufeature_patch_func(struct alt_entry *begin,
}
}
#endif
+
+/*
+ * Compute the set of profile bases (IMA, RVA23U64, ...) a hart
+ * conforms to, given its resolved ISA bitmap.
+ *
+ * If @isa_bitmap is NULL, the host ISA bitmap (the AND across all harts) is
+ * used.
+ */
+static void riscv_set_isa_bases(unsigned long *bases, const unsigned long *isa_bitmap)
+{
+ const unsigned long *isa = isa_bitmap ? isa_bitmap : riscv_isa;
+ DECLARE_BITMAP(ext_mask, RISCV_ISA_EXT_MAX) = { 0 };
+ DECLARE_BITMAP(tmp, RISCV_ISA_EXT_MAX);
+
+ /* IMA */
+ set_bit(RISCV_ISA_EXT_I, ext_mask);
+ set_bit(RISCV_ISA_EXT_M, ext_mask);
+ set_bit(RISCV_ISA_EXT_A, ext_mask);
+
+ if (bitmap_andnot(tmp, ext_mask, isa, RISCV_ISA_EXT_MAX))
+ return;
+
+ set_bit(RISCV_ISA_BASE_IMA, bases);
+
+ /* RVA23U64 */
+
+ /* Zic64b and Supm with PMLEN=7 */
+ if (riscv_cbom_block_size != 64 ||
+ riscv_cbop_block_size != 64 ||
+ riscv_cboz_block_size != 64 ||
+ !riscv_have_user_pmlen(7))
+ return;
+
+ set_bit(RISCV_ISA_EXT_F, ext_mask);
+ set_bit(RISCV_ISA_EXT_D, ext_mask);
+ set_bit(RISCV_ISA_EXT_C, ext_mask);
+ set_bit(RISCV_ISA_EXT_B, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZICSR, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZICNTR, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZIHPM, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZICCIF, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZICCRSE, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZICCAMOA, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZICCLSM, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZA64RS, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZIHINTPAUSE, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZICBOM, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZICBOP, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZICBOZ, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZFHMIN, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZKT, ext_mask);
+ set_bit(RISCV_ISA_EXT_V, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZVFHMIN, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZVBB, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZVKT, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZIHINTNTL, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZICOND, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZIMOP, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZCMOP, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZCB, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZFA, ext_mask);
+ set_bit(RISCV_ISA_EXT_ZAWRS, ext_mask);
+ set_bit(RISCV_ISA_EXT_SUPM, ext_mask);
+
+ if (bitmap_andnot(tmp, ext_mask, isa, RISCV_ISA_EXT_MAX))
+ return;
+
+ set_bit(RISCV_ISA_BASE_RVA23U64, bases);
+}
+
+/*
+ * Populate the host ISA bases bitmap (riscv_isa_bases) and each
+ * hart's per-cpu isa_bases.
+ */
+static int __init riscv_init_isa_bases(void)
+{
+ int cpu;
+
+ for_each_possible_cpu(cpu)
+ riscv_set_isa_bases(hart_isa[cpu].isa_bases, hart_isa[cpu].isa);
+
+ riscv_set_isa_bases(riscv_isa_bases, NULL);
+ return 0;
+}
+/*
+ * Registered as subsys_initcall so it runs after
+ * core_initcall(tagged_addr_init) populates have_user_pmlen_*.
+ */
+subsys_initcall(riscv_init_isa_bases);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 07/10] riscv: Add a getter for user PMLEN support
From: Guodong Xu @ 2026-05-12 1:34 UTC (permalink / raw)
To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner
Cc: Andrew Jones, Charlie Jenkins, Samuel Holland, linux-doc,
linux-riscv, linux-kernel, linux-kselftest, kvm, kvm-riscv,
Guodong Xu
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc@riscstar.com>
From: Andrew Jones <andrew.jones@oss.qualcomm.com>
Querying whether a given user PMLEN is supported is needed for
RVA23U64 base detection from outside arch/riscv/kernel/process.c.
Add riscv_have_user_pmlen() to expose this.
Link: https://lore.kernel.org/linux-riscv/rfuwa7a3ebe76udmnwyrssjy7shkkgxntvhwzn6oquysj4tuyp@xzvpylcfhz53/
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
[Guodong: replace exported booleans with getter per Andrew's suggestion]
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: Add a getter for user PMLEN.
---
arch/riscv/include/asm/processor.h | 4 ++++
arch/riscv/kernel/process.c | 12 ++++++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
index 812517b2cec13..febf51e127f70 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -214,6 +214,10 @@ long set_tagged_addr_ctrl(struct task_struct *task, unsigned long arg);
long get_tagged_addr_ctrl(struct task_struct *task);
#define SET_TAGGED_ADDR_CTRL(arg) set_tagged_addr_ctrl(current, arg)
#define GET_TAGGED_ADDR_CTRL() get_tagged_addr_ctrl(current)
+
+bool riscv_have_user_pmlen(u8 len);
+#else
+static inline bool riscv_have_user_pmlen(u8 len) { return false; }
#endif
#endif /* __ASSEMBLER__ */
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index b2df7f72241a5..5d9cb108a6232 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -302,6 +302,18 @@ enum {
static bool have_user_pmlen_7;
static bool have_user_pmlen_16;
+bool riscv_have_user_pmlen(u8 len)
+{
+ switch (len) {
+ case PMLEN_7:
+ return have_user_pmlen_7;
+ case PMLEN_16:
+ return have_user_pmlen_16;
+ default:
+ return false;
+ }
+}
+
/*
* Control the relaxed ABI allowing tagged user addresses into the kernel.
*/
--
2.43.0
^ permalink raw reply related
* [PATCH v2 06/10] riscv: Add B to hwcap and hwprobe
From: Guodong Xu @ 2026-05-12 1:34 UTC (permalink / raw)
To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner
Cc: Andrew Jones, Charlie Jenkins, Samuel Holland, linux-doc,
linux-riscv, linux-kernel, linux-kselftest, kvm, kvm-riscv,
Guodong Xu
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc@riscstar.com>
From: Andrew Jones <andrew.jones@oss.qualcomm.com>
Add B to hwcap and ensure when B is present that Zba, Zbb, and Zbs
are all set. Also expose B via hwprobe (RISCV_HWPROBE_EXT_B in
RISCV_HWPROBE_KEY_IMA_EXT_1) so that userspace can probe B directly,
mirroring the F/D/C/V pattern where each is reported via both hwcap
and hwprobe.
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
[Add B to hwprobe]
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2:
- Rebased to v7.1-rc2
- Add B to hwprobe (RISCV_HWPROBE_EXT_B at IMA_EXT_1 bit 6) and
document it in hwprobe.rst, so userspace can probe B directly.
---
Documentation/arch/riscv/hwprobe.rst | 4 ++++
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/include/uapi/asm/hwcap.h | 1 +
arch/riscv/include/uapi/asm/hwprobe.h | 1 +
arch/riscv/kernel/cpufeature.c | 8 ++++++++
arch/riscv/kernel/sys_hwprobe.c | 1 +
6 files changed, 16 insertions(+)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index 73f50dc1ce7a2..cb31fd3b12017 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -415,3 +415,7 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_EXT_ZA64RS`: The Za64rs extension is supported,
as defined in the RISC-V Profiles specification starting from commit
b1d80660 ("Updated to ratified state.")
+
+ * :c:macro:`RISCV_HWPROBE_EXT_B`: The B extension is supported, as defined
+ in version 1.0 of the Bit-Manipulation ISA extensions, and implies the
+ presence of the Zba, Zbb, and Zbs sub-extensions.
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 0acb7a01ecc0f..58523b3a1998a 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -11,6 +11,7 @@
#include <uapi/asm/hwcap.h>
#define RISCV_ISA_EXT_A ('a' - 'a')
+#define RISCV_ISA_EXT_B ('b' - 'a')
#define RISCV_ISA_EXT_C ('c' - 'a')
#define RISCV_ISA_EXT_D ('d' - 'a')
#define RISCV_ISA_EXT_F ('f' - 'a')
diff --git a/arch/riscv/include/uapi/asm/hwcap.h b/arch/riscv/include/uapi/asm/hwcap.h
index c52bb7bbbabe9..96b7cf854e090 100644
--- a/arch/riscv/include/uapi/asm/hwcap.h
+++ b/arch/riscv/include/uapi/asm/hwcap.h
@@ -21,6 +21,7 @@
#define COMPAT_HWCAP_ISA_F (1 << ('F' - 'A'))
#define COMPAT_HWCAP_ISA_D (1 << ('D' - 'A'))
#define COMPAT_HWCAP_ISA_C (1 << ('C' - 'A'))
+#define COMPAT_HWCAP_ISA_B (1 << ('B' - 'A'))
#define COMPAT_HWCAP_ISA_V (1 << ('V' - 'A'))
#endif /* _UAPI_ASM_RISCV_HWCAP_H */
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 58d1e86e47ae7..430dc49a82863 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -121,6 +121,7 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_EXT_ZICCIF (1ULL << 3)
#define RISCV_HWPROBE_EXT_ZICCRSE (1ULL << 4)
#define RISCV_HWPROBE_EXT_ZA64RS (1ULL << 5)
+#define RISCV_HWPROBE_EXT_B (1ULL << 6)
/* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 46ea2cbcf881a..81145621dc378 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -468,6 +468,12 @@ static const unsigned int riscv_c_exts[] = {
RISCV_ISA_EXT_ZCD,
};
+static const unsigned int riscv_b_exts[] = {
+ RISCV_ISA_EXT_ZBA,
+ RISCV_ISA_EXT_ZBB,
+ RISCV_ISA_EXT_ZBS,
+};
+
/*
* The canonical order of ISA extension names in the ISA string is defined in
* chapter 27 of the unprivileged specification.
@@ -515,6 +521,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA_VALIDATE(d, RISCV_ISA_EXT_D, riscv_ext_d_validate),
__RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_Q),
__RISCV_ISA_EXT_SUPERSET(c, RISCV_ISA_EXT_C, riscv_c_exts),
+ __RISCV_ISA_EXT_SUPERSET(b, RISCV_ISA_EXT_B, riscv_b_exts),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(v, RISCV_ISA_EXT_V, riscv_v_exts, riscv_ext_vector_float_validate),
__RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_H),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
@@ -1135,6 +1142,7 @@ void __init riscv_fill_hwcap(void)
isa2hwcap['f' - 'a'] = COMPAT_HWCAP_ISA_F;
isa2hwcap['d' - 'a'] = COMPAT_HWCAP_ISA_D;
isa2hwcap['c' - 'a'] = COMPAT_HWCAP_ISA_C;
+ isa2hwcap['b' - 'a'] = COMPAT_HWCAP_ISA_B;
isa2hwcap['v' - 'a'] = COMPAT_HWCAP_ISA_V;
if (!acpi_disabled) {
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index b15ac9adf7920..dcc102bf8f183 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -210,6 +210,7 @@ static void hwprobe_isa_ext1(struct riscv_hwprobe *pair,
EXT_KEY(isainfo->isa, ZICCIF, pair->value, missing);
EXT_KEY(isainfo->isa, ZICCRSE, pair->value, missing);
EXT_KEY(isainfo->isa, ZA64RS, pair->value, missing);
+ EXT_KEY(isainfo->isa, B, pair->value, missing);
}
/* Now turn off reporting features if any CPU is missing it. */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 05/10] riscv: Add Ziccamoa, Ziccif, Ziccrse, and Za64rs to cpufeature and hwprobe
From: Guodong Xu @ 2026-05-12 1:34 UTC (permalink / raw)
To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner
Cc: Andrew Jones, Charlie Jenkins, Samuel Holland, linux-doc,
linux-riscv, linux-kernel, linux-kselftest, kvm, kvm-riscv,
Guodong Xu
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc@riscstar.com>
From: Andrew Jones <andrew.jones@oss.qualcomm.com>
Add Ziccamoa, Ziccif, and Za64rs to riscv_isa_ext[] so they can be
parsed from devicetree/ACPI ISA strings. Ziccrse is already present
in cpufeature; this patch only adds its hwprobe exposure.
Expose all four extensions via hwprobe through new bits in
RISCV_HWPROBE_KEY_IMA_EXT_1 (RISCV_HWPROBE_EXT_ZICCAMOA, _ZICCIF,
_ZICCRSE, _ZA64RS), so userspace can probe each of these
RVA23U64-mandatory extensions individually.
Rationale for the validation dependencies added for Ziccamoa and Za64rs:
1) Ziccamoa depends on Zaamo. The RVA23 profile prose was updated
post-ratification to spell out the Zaamo reference: commit
2b218613752d in riscv/riscv-profiles ("Improve description of
Ziccamoa (#224)") reworded the rva23-profile.adoc (and other profiles
that include Ziccamoa) text from "must support all atomics in A" to
"must support all atomics in the Zaamo extension" [1].
2) Za64rs depends on Zalrsc. The unprivileged ISA manual src/zars.adoc,
integrated in commit ebe06adc22cd ("Integrate profiles as Volume III
(#2771)"), defines Za64rs as: "The Za64rs extension requires that the
reservation sets used by the instructions in the Zalrsc extension be
contiguous, naturally aligned, and at most 64 bytes in size" [2].
Link: https://github.com/riscv/riscv-profiles/commit/2b218613752d63287286b5ae801b820cbd8cc10c [1]
Link: https://github.com/riscv/riscv-isa-manual/blob/main/src/unpriv/zars.adoc [2]
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2:
- Rebased to v7.1-rc2.
- Reworded subject and expanded commit message.
- Validation added for Ziccamoa depending on Zaamo and Za64rs depending
on Zalrsc.
---
Documentation/arch/riscv/hwprobe.rst | 16 ++++++++++++++++
arch/riscv/include/asm/hwcap.h | 3 +++
arch/riscv/include/uapi/asm/hwprobe.h | 4 ++++
arch/riscv/kernel/cpufeature.c | 21 +++++++++++++++++++++
arch/riscv/kernel/sys_hwprobe.c | 4 ++++
5 files changed, 48 insertions(+)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index 05f746061f679..73f50dc1ce7a2 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -399,3 +399,19 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_EXT_ZICFISS`: The Zicfiss extension is supported,
as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI)
extensions specification, ratified 2024-07.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICCAMOA`: The Ziccamoa extension is supported,
+ as defined in the RISC-V Profiles specification starting from commit
+ b1d80660 ("Updated to ratified state.")
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICCIF`: The Ziccif extension is supported,
+ as defined in the RISC-V Profiles specification starting from commit
+ b1d80660 ("Updated to ratified state.")
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICCRSE`: The Ziccrse extension is supported,
+ as defined in the RISC-V Profiles specification starting from commit
+ b1d80660 ("Updated to ratified state.")
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZA64RS`: The Za64rs extension is supported,
+ as defined in the RISC-V Profiles specification starting from commit
+ b1d80660 ("Updated to ratified state.")
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index e8f4a7dd96a93..0acb7a01ecc0f 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -113,6 +113,9 @@
#define RISCV_ISA_EXT_ZICFILP 104
#define RISCV_ISA_EXT_ZICFISS 105
#define RISCV_ISA_EXT_ZICCLSM 106
+#define RISCV_ISA_EXT_ZICCAMOA 107
+#define RISCV_ISA_EXT_ZICCIF 108
+#define RISCV_ISA_EXT_ZA64RS 109
#define RISCV_ISA_EXT_XLINUXENVCFG 127
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 6819df159c51e..58d1e86e47ae7 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -117,6 +117,10 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_KEY_IMA_EXT_1 16
#define RISCV_HWPROBE_EXT_ZICFISS (1ULL << 0)
#define RISCV_HWPROBE_EXT_ZICCLSM (1ULL << 1)
+#define RISCV_HWPROBE_EXT_ZICCAMOA (1ULL << 2)
+#define RISCV_HWPROBE_EXT_ZICCIF (1ULL << 3)
+#define RISCV_HWPROBE_EXT_ZICCRSE (1ULL << 4)
+#define RISCV_HWPROBE_EXT_ZA64RS (1ULL << 5)
/* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 4b4a8157277a3..46ea2cbcf881a 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -90,6 +90,24 @@ static int riscv_ext_f_depends(const struct riscv_isa_ext_data *data,
return -EPROBE_DEFER;
}
+static int riscv_ext_zaamo_depends(const struct riscv_isa_ext_data *data,
+ const unsigned long *isa_bitmap)
+{
+ if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZAAMO))
+ return 0;
+
+ return -EPROBE_DEFER;
+}
+
+static int riscv_ext_zalrsc_depends(const struct riscv_isa_ext_data *data,
+ const unsigned long *isa_bitmap)
+{
+ if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZALRSC))
+ return 0;
+
+ return -EPROBE_DEFER;
+}
+
static int riscv_ext_zicbom_validate(const struct riscv_isa_ext_data *data,
const unsigned long *isa_bitmap)
{
@@ -502,6 +520,8 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),
+ __RISCV_ISA_EXT_DATA_VALIDATE(ziccamoa, RISCV_ISA_EXT_ZICCAMOA, riscv_ext_zaamo_depends),
+ __RISCV_ISA_EXT_DATA(ziccif, RISCV_ISA_EXT_ZICCIF),
__RISCV_ISA_EXT_DATA(zicclsm, RISCV_ISA_EXT_ZICCLSM),
__RISCV_ISA_EXT_DATA(ziccrse, RISCV_ISA_EXT_ZICCRSE),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicfilp, RISCV_ISA_EXT_ZICFILP, riscv_xlinuxenvcfg_exts,
@@ -516,6 +536,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_DATA(zihintpause, RISCV_ISA_EXT_ZIHINTPAUSE),
__RISCV_ISA_EXT_DATA(zihpm, RISCV_ISA_EXT_ZIHPM),
__RISCV_ISA_EXT_DATA(zimop, RISCV_ISA_EXT_ZIMOP),
+ __RISCV_ISA_EXT_DATA_VALIDATE(za64rs, RISCV_ISA_EXT_ZA64RS, riscv_ext_zalrsc_depends),
__RISCV_ISA_EXT_DATA(zaamo, RISCV_ISA_EXT_ZAAMO),
__RISCV_ISA_EXT_DATA(zabha, RISCV_ISA_EXT_ZABHA),
__RISCV_ISA_EXT_DATA(zacas, RISCV_ISA_EXT_ZACAS),
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index 9cf62266f1890..b15ac9adf7920 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -206,6 +206,10 @@ static void hwprobe_isa_ext1(struct riscv_hwprobe *pair,
*/
EXT_KEY(isainfo->isa, ZICFISS, pair->value, missing);
EXT_KEY(isainfo->isa, ZICCLSM, pair->value, missing);
+ EXT_KEY(isainfo->isa, ZICCAMOA, pair->value, missing);
+ EXT_KEY(isainfo->isa, ZICCIF, pair->value, missing);
+ EXT_KEY(isainfo->isa, ZICCRSE, pair->value, missing);
+ EXT_KEY(isainfo->isa, ZA64RS, pair->value, missing);
}
/* Now turn off reporting features if any CPU is missing it. */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 04/10] riscv: Add Zicclsm to cpufeature and hwprobe
From: Guodong Xu @ 2026-05-12 1:34 UTC (permalink / raw)
To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner
Cc: Andrew Jones, Charlie Jenkins, Samuel Holland, linux-doc,
linux-riscv, linux-kernel, linux-kselftest, kvm, kvm-riscv,
Guodong Xu, Jesse Taube, Andy Chiu
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc@riscstar.com>
From: Jesse Taube <jesse@rivosinc.com>
Zicclsm requires misaligned support for all regular load and store
instructions, both scalar and vector, but not AMOs or other
specialized forms of memory access, to main memory regions with both
the cacheability and coherence PMAs, as defined in the profiles spec.
Even though mandated, misaligned loads and stores might execute
extremely slowly. Standard software distributions should assume their
existence only for correctness, not for performance.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andy Chiu <andy.chiu@sifive.com>
Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
Tested-by: Charlie Jenkins <charlie@rivosinc.com>
Signed-off-by: Jesse Taube <jesse@rivosinc.com>
[Rebased, rewrote doc text, minor commit message revisions]
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2:
- Rebased onto v7.1-rc2; moved ZICCLSM to IMA_EXT_1 and
allocated a new bit for it
---
Documentation/arch/riscv/hwprobe.rst | 4 ++++
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/include/uapi/asm/hwprobe.h | 1 +
arch/riscv/kernel/cpufeature.c | 1 +
arch/riscv/kernel/sys_hwprobe.c | 1 +
5 files changed, 8 insertions(+)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index c3bb26d70c748..05f746061f679 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -289,6 +289,10 @@ The following keys are defined:
defined in the RISC-V ISA manual starting from commit f88abf1 ("Integrating
load/store pair for RV32 with the main manual") of the riscv-isa-manual.
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICCLSM`: The Zicclsm extension is supported,
+ as defined in the RISC-V Profiles specification starting from commit
+ b1d80660 ("Updated to ratified state.")
+
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: Deprecated. Returns similar values to
:c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`, but the key was
mistakenly classified as a bitmask rather than a value.
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 44bf8c7d8acc5..e8f4a7dd96a93 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -112,6 +112,7 @@
#define RISCV_ISA_EXT_ZCLSD 103
#define RISCV_ISA_EXT_ZICFILP 104
#define RISCV_ISA_EXT_ZICFISS 105
+#define RISCV_ISA_EXT_ZICCLSM 106
#define RISCV_ISA_EXT_XLINUXENVCFG 127
diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
index 9139edba0aecb..6819df159c51e 100644
--- a/arch/riscv/include/uapi/asm/hwprobe.h
+++ b/arch/riscv/include/uapi/asm/hwprobe.h
@@ -116,6 +116,7 @@ struct riscv_hwprobe {
#define RISCV_HWPROBE_KEY_ZICBOP_BLOCK_SIZE 15
#define RISCV_HWPROBE_KEY_IMA_EXT_1 16
#define RISCV_HWPROBE_EXT_ZICFISS (1ULL << 0)
+#define RISCV_HWPROBE_EXT_ZICCLSM (1ULL << 1)
/* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 5cf463570229d..4b4a8157277a3 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -502,6 +502,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),
+ __RISCV_ISA_EXT_DATA(zicclsm, RISCV_ISA_EXT_ZICCLSM),
__RISCV_ISA_EXT_DATA(ziccrse, RISCV_ISA_EXT_ZICCRSE),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicfilp, RISCV_ISA_EXT_ZICFILP, riscv_xlinuxenvcfg_exts,
riscv_cfilp_validate),
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index f8f68ba781b45..9cf62266f1890 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -205,6 +205,7 @@ static void hwprobe_isa_ext1(struct riscv_hwprobe *pair,
* in the hart_isa bitmap, are made.
*/
EXT_KEY(isainfo->isa, ZICFISS, pair->value, missing);
+ EXT_KEY(isainfo->isa, ZICCLSM, pair->value, missing);
}
/* Now turn off reporting features if any CPU is missing it. */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 03/10] riscv: Standardize extension capitalization
From: Guodong Xu @ 2026-05-12 1:34 UTC (permalink / raw)
To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner
Cc: Andrew Jones, Charlie Jenkins, Samuel Holland, linux-doc,
linux-riscv, linux-kernel, linux-kselftest, kvm, kvm-riscv,
Guodong Xu, Charlie Jenkins
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc@riscstar.com>
From: Charlie Jenkins <charlie@rivosinc.com>
The base extensions are often lowercase and were written as lowercase in
hwcap, but other references to these extensions in the kernel are
uppercase. Standardize the case to make it easier to handle macro
expansion.
Signed-off-by: Charlie Jenkins <thecharlesjenkins@gmail.com>
[Apply KVM_ISA_EXT_ARR(), fixup all KVM use.]
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2:
- Rebased onto v7.1-rc2.
- KVM_ISA_EXT_ARR() consolidation moved to its new upstream location
(kvm/isa.c); host-side checks now use kvm_riscv_isa_check_host().
---
arch/riscv/include/asm/hwcap.h | 18 +++++++++---------
arch/riscv/include/asm/switch_to.h | 4 ++--
arch/riscv/kernel/cpufeature.c | 32 ++++++++++++++++----------------
arch/riscv/kernel/sys_hwprobe.c | 4 ++--
arch/riscv/kvm/isa.c | 16 ++++++++--------
arch/riscv/kvm/main.c | 2 +-
arch/riscv/kvm/vcpu_fp.c | 20 ++++++++++----------
arch/riscv/kvm/vcpu_onereg.c | 6 +++---
arch/riscv/kvm/vcpu_vector.c | 10 +++++-----
9 files changed, 56 insertions(+), 56 deletions(-)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 7ef8e5f55c8dc..44bf8c7d8acc5 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -10,15 +10,15 @@
#include <uapi/asm/hwcap.h>
-#define RISCV_ISA_EXT_a ('a' - 'a')
-#define RISCV_ISA_EXT_c ('c' - 'a')
-#define RISCV_ISA_EXT_d ('d' - 'a')
-#define RISCV_ISA_EXT_f ('f' - 'a')
-#define RISCV_ISA_EXT_h ('h' - 'a')
-#define RISCV_ISA_EXT_i ('i' - 'a')
-#define RISCV_ISA_EXT_m ('m' - 'a')
-#define RISCV_ISA_EXT_q ('q' - 'a')
-#define RISCV_ISA_EXT_v ('v' - 'a')
+#define RISCV_ISA_EXT_A ('a' - 'a')
+#define RISCV_ISA_EXT_C ('c' - 'a')
+#define RISCV_ISA_EXT_D ('d' - 'a')
+#define RISCV_ISA_EXT_F ('f' - 'a')
+#define RISCV_ISA_EXT_H ('h' - 'a')
+#define RISCV_ISA_EXT_I ('i' - 'a')
+#define RISCV_ISA_EXT_M ('m' - 'a')
+#define RISCV_ISA_EXT_Q ('q' - 'a')
+#define RISCV_ISA_EXT_V ('v' - 'a')
/*
* These macros represent the logical IDs of each multi-letter RISC-V ISA
diff --git a/arch/riscv/include/asm/switch_to.h b/arch/riscv/include/asm/switch_to.h
index 0e71eb82f920c..ff35a4d04f85a 100644
--- a/arch/riscv/include/asm/switch_to.h
+++ b/arch/riscv/include/asm/switch_to.h
@@ -60,8 +60,8 @@ static inline void __switch_to_fpu(struct task_struct *prev,
static __always_inline bool has_fpu(void)
{
- return riscv_has_extension_likely(RISCV_ISA_EXT_f) ||
- riscv_has_extension_likely(RISCV_ISA_EXT_d);
+ return riscv_has_extension_likely(RISCV_ISA_EXT_F) ||
+ riscv_has_extension_likely(RISCV_ISA_EXT_D);
}
#else
static __always_inline bool has_fpu(void) { return false; }
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index 1734f9a4c2fd7..5cf463570229d 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -84,7 +84,7 @@ EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
static int riscv_ext_f_depends(const struct riscv_isa_ext_data *data,
const unsigned long *isa_bitmap)
{
- if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_f))
+ if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_F))
return 0;
return -EPROBE_DEFER;
@@ -146,7 +146,7 @@ static int riscv_ext_f_validate(const struct riscv_isa_ext_data *data,
* Due to extension ordering, d is checked before f, so no deferral
* is required.
*/
- if (!__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_d)) {
+ if (!__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_D)) {
pr_warn_once("This kernel does not support systems with F but not D\n");
return -EINVAL;
}
@@ -189,7 +189,7 @@ static int riscv_ext_vector_float_validate(const struct riscv_isa_ext_data *data
* Since this function validates vector only, and v/Zve* are probed
* after f/d, there's no need for a deferral here.
*/
- if (!__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_d))
+ if (!__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_D))
return -EINVAL;
return 0;
@@ -224,7 +224,7 @@ static int riscv_ext_zcd_validate(const struct riscv_isa_ext_data *data,
const unsigned long *isa_bitmap)
{
if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZCA) &&
- __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_d))
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_D))
return 0;
return -EPROBE_DEFER;
@@ -237,7 +237,7 @@ static int riscv_ext_zcf_validate(const struct riscv_isa_ext_data *data,
return -EINVAL;
if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_ZCA) &&
- __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_f))
+ __riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_F))
return 0;
return -EPROBE_DEFER;
@@ -490,15 +490,15 @@ static const unsigned int riscv_c_exts[] = {
* New entries to this struct should follow the ordering rules described above.
*/
const struct riscv_isa_ext_data riscv_isa_ext[] = {
- __RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_i),
- __RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_m),
- __RISCV_ISA_EXT_SUPERSET(a, RISCV_ISA_EXT_a, riscv_a_exts),
- __RISCV_ISA_EXT_DATA_VALIDATE(f, RISCV_ISA_EXT_f, riscv_ext_f_validate),
- __RISCV_ISA_EXT_DATA_VALIDATE(d, RISCV_ISA_EXT_d, riscv_ext_d_validate),
- __RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_q),
- __RISCV_ISA_EXT_SUPERSET(c, RISCV_ISA_EXT_c, riscv_c_exts),
- __RISCV_ISA_EXT_SUPERSET_VALIDATE(v, RISCV_ISA_EXT_v, riscv_v_exts, riscv_ext_vector_float_validate),
- __RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_h),
+ __RISCV_ISA_EXT_DATA(i, RISCV_ISA_EXT_I),
+ __RISCV_ISA_EXT_DATA(m, RISCV_ISA_EXT_M),
+ __RISCV_ISA_EXT_SUPERSET(a, RISCV_ISA_EXT_A, riscv_a_exts),
+ __RISCV_ISA_EXT_DATA_VALIDATE(f, RISCV_ISA_EXT_F, riscv_ext_f_validate),
+ __RISCV_ISA_EXT_DATA_VALIDATE(d, RISCV_ISA_EXT_D, riscv_ext_d_validate),
+ __RISCV_ISA_EXT_DATA(q, RISCV_ISA_EXT_Q),
+ __RISCV_ISA_EXT_SUPERSET(c, RISCV_ISA_EXT_C, riscv_c_exts),
+ __RISCV_ISA_EXT_SUPERSET_VALIDATE(v, RISCV_ISA_EXT_V, riscv_v_exts, riscv_ext_vector_float_validate),
+ __RISCV_ISA_EXT_DATA(h, RISCV_ISA_EXT_H),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
__RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
__RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),
@@ -897,8 +897,8 @@ static void __init riscv_fill_hwcap_from_isa_string(unsigned long *isa2hwcap)
* marchid.
*/
if (acpi_disabled && boot_vendorid == THEAD_VENDOR_ID && boot_archid == 0x0) {
- this_hwcap &= ~isa2hwcap[RISCV_ISA_EXT_v];
- clear_bit(RISCV_ISA_EXT_v, source_isa);
+ this_hwcap &= ~isa2hwcap[RISCV_ISA_EXT_V];
+ clear_bit(RISCV_ISA_EXT_V, source_isa);
}
riscv_resolve_isa(source_isa, isainfo->isa, &this_hwcap, isa2hwcap);
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index 1659d31fd288f..f8f68ba781b45 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -88,10 +88,10 @@ static void hwprobe_isa_ext0(struct riscv_hwprobe *pair,
if (has_fpu())
pair->value |= RISCV_HWPROBE_IMA_FD;
- if (riscv_isa_extension_available(NULL, c))
+ if (riscv_isa_extension_available(NULL, C))
pair->value |= RISCV_HWPROBE_IMA_C;
- if (has_vector() && riscv_isa_extension_available(NULL, v))
+ if (has_vector() && riscv_isa_extension_available(NULL, V))
pair->value |= RISCV_HWPROBE_IMA_V;
/*
diff --git a/arch/riscv/kvm/isa.c b/arch/riscv/kvm/isa.c
index 1132d909cc25c..94077117d1136 100644
--- a/arch/riscv/kvm/isa.c
+++ b/arch/riscv/kvm/isa.c
@@ -17,14 +17,14 @@
/* Mapping between KVM ISA Extension ID & guest ISA extension ID */
static const unsigned long kvm_isa_ext_arr[] = {
/* Single letter extensions (alphabetically sorted) */
- [KVM_RISCV_ISA_EXT_A] = RISCV_ISA_EXT_a,
- [KVM_RISCV_ISA_EXT_C] = RISCV_ISA_EXT_c,
- [KVM_RISCV_ISA_EXT_D] = RISCV_ISA_EXT_d,
- [KVM_RISCV_ISA_EXT_F] = RISCV_ISA_EXT_f,
- [KVM_RISCV_ISA_EXT_H] = RISCV_ISA_EXT_h,
- [KVM_RISCV_ISA_EXT_I] = RISCV_ISA_EXT_i,
- [KVM_RISCV_ISA_EXT_M] = RISCV_ISA_EXT_m,
- [KVM_RISCV_ISA_EXT_V] = RISCV_ISA_EXT_v,
+ KVM_ISA_EXT_ARR(A),
+ KVM_ISA_EXT_ARR(C),
+ KVM_ISA_EXT_ARR(D),
+ KVM_ISA_EXT_ARR(F),
+ KVM_ISA_EXT_ARR(H),
+ KVM_ISA_EXT_ARR(I),
+ KVM_ISA_EXT_ARR(M),
+ KVM_ISA_EXT_ARR(V),
/* Multi letter extensions (alphabetically sorted) */
KVM_ISA_EXT_ARR(SMNPM),
KVM_ISA_EXT_ARR(SMSTATEEN),
diff --git a/arch/riscv/kvm/main.c b/arch/riscv/kvm/main.c
index cb8a65273c1f0..70640701310c8 100644
--- a/arch/riscv/kvm/main.c
+++ b/arch/riscv/kvm/main.c
@@ -85,7 +85,7 @@ static int __init riscv_kvm_init(void)
char slist[64];
const char *str;
- if (!riscv_isa_extension_available(NULL, h)) {
+ if (!riscv_isa_extension_available(NULL, H)) {
kvm_info("hypervisor extension not available\n");
return -ENODEV;
}
diff --git a/arch/riscv/kvm/vcpu_fp.c b/arch/riscv/kvm/vcpu_fp.c
index 6ad6df26a2fd4..bb11e6757d349 100644
--- a/arch/riscv/kvm/vcpu_fp.c
+++ b/arch/riscv/kvm/vcpu_fp.c
@@ -21,8 +21,8 @@ void kvm_riscv_vcpu_fp_reset(struct kvm_vcpu *vcpu)
struct kvm_cpu_context *cntx = &vcpu->arch.guest_context;
cntx->sstatus &= ~SR_FS;
- if (riscv_isa_extension_available(vcpu->arch.isa, f) ||
- riscv_isa_extension_available(vcpu->arch.isa, d))
+ if (riscv_isa_extension_available(vcpu->arch.isa, F) ||
+ riscv_isa_extension_available(vcpu->arch.isa, D))
cntx->sstatus |= SR_FS_INITIAL;
else
cntx->sstatus |= SR_FS_OFF;
@@ -38,9 +38,9 @@ void kvm_riscv_vcpu_guest_fp_save(struct kvm_cpu_context *cntx,
const unsigned long *isa)
{
if ((cntx->sstatus & SR_FS) == SR_FS_DIRTY) {
- if (riscv_isa_extension_available(isa, d))
+ if (riscv_isa_extension_available(isa, D))
__kvm_riscv_fp_d_save(cntx);
- else if (riscv_isa_extension_available(isa, f))
+ else if (riscv_isa_extension_available(isa, F))
__kvm_riscv_fp_f_save(cntx);
kvm_riscv_vcpu_fp_clean(cntx);
}
@@ -50,9 +50,9 @@ void kvm_riscv_vcpu_guest_fp_restore(struct kvm_cpu_context *cntx,
const unsigned long *isa)
{
if ((cntx->sstatus & SR_FS) != SR_FS_OFF) {
- if (riscv_isa_extension_available(isa, d))
+ if (riscv_isa_extension_available(isa, D))
__kvm_riscv_fp_d_restore(cntx);
- else if (riscv_isa_extension_available(isa, f))
+ else if (riscv_isa_extension_available(isa, F))
__kvm_riscv_fp_f_restore(cntx);
kvm_riscv_vcpu_fp_clean(cntx);
}
@@ -89,7 +89,7 @@ int kvm_riscv_vcpu_get_reg_fp(struct kvm_vcpu *vcpu,
void *reg_val;
if ((rtype == KVM_REG_RISCV_FP_F) &&
- riscv_isa_extension_available(vcpu->arch.isa, f)) {
+ riscv_isa_extension_available(vcpu->arch.isa, F)) {
if (KVM_REG_SIZE(reg->id) != sizeof(u32))
return -EINVAL;
if (reg_num == KVM_REG_RISCV_FP_F_REG(fcsr))
@@ -102,7 +102,7 @@ int kvm_riscv_vcpu_get_reg_fp(struct kvm_vcpu *vcpu,
} else
return -ENOENT;
} else if ((rtype == KVM_REG_RISCV_FP_D) &&
- riscv_isa_extension_available(vcpu->arch.isa, d)) {
+ riscv_isa_extension_available(vcpu->arch.isa, D)) {
if (reg_num == KVM_REG_RISCV_FP_D_REG(fcsr)) {
if (KVM_REG_SIZE(reg->id) != sizeof(u32))
return -EINVAL;
@@ -138,7 +138,7 @@ int kvm_riscv_vcpu_set_reg_fp(struct kvm_vcpu *vcpu,
void *reg_val;
if ((rtype == KVM_REG_RISCV_FP_F) &&
- riscv_isa_extension_available(vcpu->arch.isa, f)) {
+ riscv_isa_extension_available(vcpu->arch.isa, F)) {
if (KVM_REG_SIZE(reg->id) != sizeof(u32))
return -EINVAL;
if (reg_num == KVM_REG_RISCV_FP_F_REG(fcsr))
@@ -151,7 +151,7 @@ int kvm_riscv_vcpu_set_reg_fp(struct kvm_vcpu *vcpu,
} else
return -ENOENT;
} else if ((rtype == KVM_REG_RISCV_FP_D) &&
- riscv_isa_extension_available(vcpu->arch.isa, d)) {
+ riscv_isa_extension_available(vcpu->arch.isa, D)) {
if (reg_num == KVM_REG_RISCV_FP_D_REG(fcsr)) {
if (KVM_REG_SIZE(reg->id) != sizeof(u32))
return -EINVAL;
diff --git a/arch/riscv/kvm/vcpu_onereg.c b/arch/riscv/kvm/vcpu_onereg.c
index bb920e8923c93..5cc7ddd4aa276 100644
--- a/arch/riscv/kvm/vcpu_onereg.c
+++ b/arch/riscv/kvm/vcpu_onereg.c
@@ -770,7 +770,7 @@ static inline unsigned long num_fp_f_regs(const struct kvm_vcpu *vcpu)
{
const struct kvm_cpu_context *cntx = &vcpu->arch.guest_context;
- if (riscv_isa_extension_available(vcpu->arch.isa, f))
+ if (riscv_isa_extension_available(vcpu->arch.isa, F))
return sizeof(cntx->fp.f) / sizeof(u32);
else
return 0;
@@ -799,7 +799,7 @@ static inline unsigned long num_fp_d_regs(const struct kvm_vcpu *vcpu)
{
const struct kvm_cpu_context *cntx = &vcpu->arch.guest_context;
- if (riscv_isa_extension_available(vcpu->arch.isa, d))
+ if (riscv_isa_extension_available(vcpu->arch.isa, D))
return sizeof(cntx->fp.d.f) / sizeof(u64) + 1;
else
return 0;
@@ -878,7 +878,7 @@ static inline unsigned long num_sbi_regs(struct kvm_vcpu *vcpu)
static inline unsigned long num_vector_regs(const struct kvm_vcpu *vcpu)
{
- if (!riscv_isa_extension_available(vcpu->arch.isa, v))
+ if (!riscv_isa_extension_available(vcpu->arch.isa, V))
return 0;
/* vstart, vl, vtype, vcsr, vlenb and 32 vector regs */
diff --git a/arch/riscv/kvm/vcpu_vector.c b/arch/riscv/kvm/vcpu_vector.c
index 62d2fb77bb9b9..f26108a4e601e 100644
--- a/arch/riscv/kvm/vcpu_vector.c
+++ b/arch/riscv/kvm/vcpu_vector.c
@@ -26,7 +26,7 @@ void kvm_riscv_vcpu_vector_reset(struct kvm_vcpu *vcpu)
cntx->vector.vlenb = riscv_v_vsize / 32;
- if (riscv_isa_extension_available(isa, v)) {
+ if (riscv_isa_extension_available(isa, V)) {
cntx->sstatus |= SR_VS_INITIAL;
WARN_ON(!cntx->vector.datap);
memset(cntx->vector.datap, 0, riscv_v_vsize);
@@ -45,7 +45,7 @@ void kvm_riscv_vcpu_guest_vector_save(struct kvm_cpu_context *cntx,
unsigned long *isa)
{
if ((cntx->sstatus & SR_VS) == SR_VS_DIRTY) {
- if (riscv_isa_extension_available(isa, v))
+ if (riscv_isa_extension_available(isa, V))
__kvm_riscv_vector_save(cntx);
kvm_riscv_vcpu_vector_clean(cntx);
}
@@ -55,7 +55,7 @@ void kvm_riscv_vcpu_guest_vector_restore(struct kvm_cpu_context *cntx,
unsigned long *isa)
{
if ((cntx->sstatus & SR_VS) != SR_VS_OFF) {
- if (riscv_isa_extension_available(isa, v))
+ if (riscv_isa_extension_available(isa, V))
__kvm_riscv_vector_restore(cntx);
kvm_riscv_vcpu_vector_clean(cntx);
}
@@ -154,7 +154,7 @@ int kvm_riscv_vcpu_get_reg_vector(struct kvm_vcpu *vcpu,
void *reg_addr;
int rc;
- if (!riscv_isa_extension_available(isa, v))
+ if (!riscv_isa_extension_available(isa, V))
return -ENOENT;
rc = kvm_riscv_vcpu_vreg_addr(vcpu, reg_num, reg_size, ®_addr);
@@ -180,7 +180,7 @@ int kvm_riscv_vcpu_set_reg_vector(struct kvm_vcpu *vcpu,
void *reg_addr;
int rc;
- if (!riscv_isa_extension_available(isa, v))
+ if (!riscv_isa_extension_available(isa, V))
return -ENOENT;
if (reg_num == KVM_REG_RISCV_VECTOR_CSR_REG(vlenb)) {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 02/10] riscv: hwprobe.rst: Replace tabs with spaces
From: Guodong Xu @ 2026-05-12 1:34 UTC (permalink / raw)
To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner
Cc: Andrew Jones, Charlie Jenkins, Samuel Holland, linux-doc,
linux-riscv, linux-kernel, linux-kselftest, kvm, kvm-riscv,
Guodong Xu
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc@riscstar.com>
From: Andrew Jones <andrew.jones@oss.qualcomm.com>
A handful of vendor-extension entries indent continuation lines with a
tab character, while the rest of hwprobe.rst uses spaces. Replace
those tabs with spaces so the file is consistently space-indented.
Cosmetic update, no functional change.
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: No change.
---
Documentation/arch/riscv/hwprobe.rst | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index b1a84ac06da75..c3bb26d70c748 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -358,7 +358,7 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XTHEADVECTOR`: The xtheadvector vendor
extension is supported in the T-Head ISA extensions spec starting from
- commit a18c801634 ("Add T-Head VECTOR vendor extension. ").
+ commit a18c801634 ("Add T-Head VECTOR vendor extension. ").
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOM_BLOCK_SIZE`: An unsigned int which
represents the size of the Zicbom block in bytes.
@@ -371,19 +371,19 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCDOD`: The Xsfqmaccdod vendor
extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
- Extensions Specification.
+ Extensions Specification.
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCQOQ`: The Xsfqmaccqoq vendor
extension is supported in version 1.1 of SiFive Int8 Matrix Multiplication
- Instruction Extensions Specification.
+ Instruction Extensions Specification.
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFNRCLIPXFQF`: The Xsfvfnrclipxfqf
vendor extension is supported in version 1.0 of SiFive FP32-to-int8 Ranged
- Clip Instructions Extensions Specification.
+ Clip Instructions Extensions Specification.
* :c:macro:`RISCV_HWPROBE_VENDOR_EXT_XSFVFWMACCQQQ`: The Xsfvfwmaccqqq
vendor extension is supported in version 1.0 of Matrix Multiply Accumulate
- Instruction Extensions Specification.
+ Instruction Extensions Specification.
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOP_BLOCK_SIZE`: An unsigned int which
represents the size of the Zicbop block in bytes.
--
2.43.0
^ permalink raw reply related
* [PATCH v2 01/10] riscv: hwprobe.rst: Document EXT_ZICFISS
From: Guodong Xu @ 2026-05-12 1:34 UTC (permalink / raw)
To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner
Cc: Andrew Jones, Charlie Jenkins, Samuel Holland, linux-doc,
linux-riscv, linux-kernel, linux-kselftest, kvm, kvm-riscv,
Guodong Xu
In-Reply-To: <20260511-rva23u64-hwprobe-v2-v2-0-21c5a544f1dc@riscstar.com>
Commit 30c3099036a9 ("riscv/hwprobe: add zicfilp / zicfiss
enumeration in hwprobe") added RISCV_HWPROBE_EXT_ZICFISS as bit 0 of
RISCV_HWPROBE_KEY_IMA_EXT_1 but did not add a matching entry to
Documentation/arch/riscv/hwprobe.rst. Add it now.
Fixes: 30c3099036a9 ("riscv/hwprobe: add zicfilp / zicfiss enumeration in hwprobe")
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
v2: New patch.
---
Documentation/arch/riscv/hwprobe.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index c420a8349bc68..b1a84ac06da75 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -391,3 +391,7 @@ The following keys are defined:
* :c:macro:`RISCV_HWPROBE_KEY_IMA_EXT_1`: A bitmask containing additional
extensions that are compatible with the
:c:macro:`RISCV_HWPROBE_BASE_BEHAVIOR_IMA`: base system behavior.
+
+ * :c:macro:`RISCV_HWPROBE_EXT_ZICFISS`: The Zicfiss extension is supported,
+ as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI)
+ extensions specification, ratified 2024-07.
--
2.43.0
^ permalink raw reply related
* [PATCH v2 00/10] riscv: hwprobe: Expose RVA23U64 base behavior
From: Guodong Xu @ 2026-05-12 1:34 UTC (permalink / raw)
To: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Conor Dooley,
Albert Ou, Alexandre Ghiti, Shuah Khan, Anup Patel, Atish Patra,
Shuah Khan, Deepak Gupta, Zong Li, Christian Brauner
Cc: Andrew Jones, Charlie Jenkins, Samuel Holland, linux-doc,
linux-riscv, linux-kernel, linux-kselftest, kvm, kvm-riscv,
Guodong Xu, Charlie Jenkins, Jesse Taube, Andy Chiu
This series builds on Andrew Jones's earlier RFC [1]. It lets
userspace check for RVA23U64 conformance in one call, instead of
walking hwprobe + prctl across every mandatory extension.
The series adds a small framework that resolves profile-class
bases (IMA and RVA23U64) from the kernel's ISA extension bitmap at
init time, and surfaces the result through both /proc/cpuinfo and
hwprobe. Later patches can add RVA23S64, and backward RVA22 / RVA20
detection, to riscv_set_isa_bases() without changes to the
surrounding code.
To detect RVA23U64 the kernel first has to recognise every extension
it mandates, so patches 4-6 bring Zicclsm; Ziccamoa, Ziccif,
Ziccrse, Za64rs; and B into the cpufeature parser. The framework
then reads the resulting bitmap, and the final patch exposes the
RVA23U64 bit through RISCV_HWPROBE_BASE_BEHAVIOR_RVA23U64.
Series outline:
1-3. hwprobe.rst clean-ups: document EXT_ZICFISS, normalize
indentation, and standardize extension capitalization.
4. Zicclsm: cpufeature parsing + hwprobe export.
5. Ziccamoa, Ziccif, Ziccrse, Za64rs: cpufeature parsing + hwprobe
export, with cpufeature dependency validation for
Ziccamoa->Zaamo and Za64rs->Zalrsc.
6. B (hwcap + hwprobe), as the Zba/Zbb/Zbs set.
7. riscv_have_user_pmlen(): arch-level accessor for user
pointer-masking PMLEN support, used by RVA23U64 detection.
8. cpufeature: per-hart and host-wide isa_bases bitmaps,
populated at init time. IMA and RVA23U64 detection lives
here; /proc/cpuinfo and hwprobe both read from these bitmaps.
9. /proc/cpuinfo: print "isa bases" / "hart isa bases" lines
sourced from the cached bitmaps.
10. hwprobe: expose RVA23U64 via
RISCV_HWPROBE_BASE_BEHAVIOR_RVA23U64.
Tested on qemu booted with -cpu rva23s64,sv39=on,pmp=on:
- /proc/cpuinfo reports "isa bases : rv64ima rva23u64" on both the
aggregated and per-hart lines.
- hwprobe RISCV_HWPROBE_KEY_BASE_BEHAVIOR returns
BASE_BEHAVIOR_IMA | BASE_BEHAVIOR_RVA23U64.
Based on v7.2-rc2; happy to rebase onto another tree if needed.
Link: https://lore.kernel.org/linux-riscv/20260206002349.96740-1-andrew.jones@oss.qualcomm.com/ [1]
BR,
Guodong Xu
Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
Andrew Jones (4):
riscv: hwprobe.rst: Replace tabs with spaces
riscv: Add Ziccamoa, Ziccif, Ziccrse, and Za64rs to cpufeature and hwprobe
riscv: Add B to hwcap and hwprobe
riscv: Add a getter for user PMLEN support
Charlie Jenkins (1):
riscv: Standardize extension capitalization
Guodong Xu (4):
riscv: hwprobe.rst: Document EXT_ZICFISS
riscv: cpufeature: Introduce ISA bases bitmap and rva23u64 detection
riscv: cpu: Output isa bases lines in cpuinfo
riscv: hwprobe: Introduce rva23u64 base behavior
Jesse Taube (1):
riscv: Add Zicclsm to cpufeature and hwprobe
Documentation/arch/riscv/hwprobe.rst | 46 +++++-
arch/riscv/include/asm/cpufeature.h | 14 ++
arch/riscv/include/asm/hwcap.h | 23 +--
arch/riscv/include/asm/processor.h | 4 +
arch/riscv/include/asm/switch_to.h | 4 +-
arch/riscv/include/uapi/asm/hwcap.h | 1 +
arch/riscv/include/uapi/asm/hwprobe.h | 9 +-
arch/riscv/kernel/cpu.c | 26 ++++
arch/riscv/kernel/cpufeature.c | 154 ++++++++++++++++++---
arch/riscv/kernel/process.c | 12 ++
arch/riscv/kernel/sys_hwprobe.c | 33 +++--
arch/riscv/kvm/isa.c | 16 +--
arch/riscv/kvm/main.c | 2 +-
arch/riscv/kvm/vcpu_fp.c | 20 +--
arch/riscv/kvm/vcpu_onereg.c | 6 +-
arch/riscv/kvm/vcpu_vector.c | 10 +-
tools/testing/selftests/riscv/hwprobe/which-cpus.c | 2 +-
17 files changed, 312 insertions(+), 70 deletions(-)
---
base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
change-id: 20260508-rva23u64-hwprobe-v2-1d20739cbb8e
Best regards,
--
Guodong Xu <guodong@riscstar.com>
^ permalink raw reply
* Re: [PATCH 2/2] scripts: checkpatch.pl: add warning for strlcat()
From: David Laight @ 2026-05-11 13:27 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Manuel Ebner, andy.shevchenko, apw, dwaipayanray1, joe, kees,
linux-doc, linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <87a4u6w3ez.fsf@trenco.lwn.net>
On Mon, 11 May 2026 06:12:36 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> Manuel Ebner <manuelebner@mailbox.org> writes:
>
> > add a warning for strlcat()
> >
> > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > ---
> > scripts/checkpatch.pl | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 0492d6afc9a1..ca1a8e67d529 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -7085,6 +7085,12 @@ sub process {
> > "Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89\n" . $herecurr);
> > }
> >
> > +# strlcat uses that should likely be
> > + if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
> > + WARN("STRLCAT",
> > + "Prefer seq_buf_printf() over strlcat - see: https://github.com/KSPP/linux/issues/370\n" . $herecurr);
> > + }
>
> Using seq_buf_printf() requires switching over to the seq_buf API in
> general, it is not just a simple substitution, so this advice may prove
> unhelpful to many.
And I'm not sure the external url is a good idea.
>
> jon
>
^ permalink raw reply
* Re: [PATCH 1/2] [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: David Laight @ 2026-05-11 13:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Manuel Ebner, andy.shevchenko, apw, corbet, dwaipayanray1, joe,
kees, linux-doc, linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <CAMuHMdWchXXcMyShiMZrhFTrHoB-TcKQEBcRoCTJFpwJsxxdhg@mail.gmail.com>
On Mon, 11 May 2026 13:40:55 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Manuel,
>
> On Sun, 10 May 2026 at 18:52, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > add strlcat and alternatives
>
> Thanks for your patch!
>
> > --- a/Documentation/process/deprecated.rst
> > +++ b/Documentation/process/deprecated.rst
> > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> > though care must be given to any cases where the return value of strlcpy()
> > is used, since strscpy() will return negative errno values when it truncates.
> >
> > +strlcat()
> > +---------
> > +strlcat() must re-scan the destination string from the beginning on each
> > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > +snprintf() and scnprintf()
>
> The last two not only require the caller to keep track of the offset
> in the buffer, but also using "%s" when storing passed strings.
Which also means they are significantly slower.
Mind you, some code has:
strlcat(buf, "\n", SIZE);
return strlen(buf);
which carefully scans the string twice.
Since the '\0' isn't always needed (eg 'show' functions), this can be:
len = strlen(buf);
buf[len] ='\n';
return len + 1;
Of course, the code could often easily get the length by other means.
-- David
>
> I hope we won't see mindless conversions lacking the "%s",
> introducing new security issues:
>
> -strlcat(buf, s, size);
> +scnprintf(buf + off, size - off, s);
>
> > +
> > %p format specifier
> > -------------------
> > Traditionally, using "%p" in format strings would lead to regular address
>
> Gr{oetje,eeting}s,
>
> Geert
>
^ permalink raw reply
* Re: [PATCH v10 8/9] platform/chrome: Protect cros_ec_device lifecycle with revocable
From: Bartosz Golaszewski @ 2026-05-11 13:19 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Arnd Bergmann, Greg Kroah-Hartman, Bartosz Golaszewski,
Linus Walleij, Benson Leung, linux-kernel, chrome-platform,
driver-core, linux-doc, linux-gpio, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Shuah Khan, Laurent Pinchart,
Wolfram Sang, Johan Hovold, Paul E . McKenney, Tzung-Bi Shih
In-Reply-To: <20260508115309.GA9254@nvidia.com>
On Fri, 8 May 2026 13:53:09 +0200, Jason Gunthorpe <jgg@nvidia.com> said:
> On Fri, May 08, 2026 at 06:54:47PM +0800, Tzung-Bi Shih wrote:
>> struct cros_ec_device *cros_ec_device_alloc(struct device *dev)
>> @@ -47,6 +49,15 @@ struct cros_ec_device *cros_ec_device_alloc(struct device *dev)
>> if (!ec_dev)
>> return NULL;
>>
>> + ec_dev->its_rev = revocable_alloc(ec_dev);
>> + if (!ec_dev->its_rev)
>> + return NULL;
>> + /*
>> + * Drop the extra reference for the caller as the caller is the
>> + * resource provider.
>> + */
>> + revocable_put(ec_dev->its_rev);
>> +
>> ec_dev->din_size = sizeof(struct ec_host_response) +
>> sizeof(struct ec_response_get_protocol_info) +
>> EC_MAX_RESPONSE_OVERHEAD;
>
> FWIW I am still very much against seeing any revokable concept used
> *between two drivers*. That will turn the kernel's lifetime model into
> spaghetti code.
>
I gave my R-b under the API definition and I'm fine with the GPIO changes.
Just for the record: I don't have an opinion on using it in this driver and
don't know if it's a good idea or not.
Bart
^ permalink raw reply
* Re: [RFC PATCH v2 1/2] scripts: add kconfirm
From: Julian Braha @ 2026-05-11 13:18 UTC (permalink / raw)
To: Jani Nikula, nathan, nsc
Cc: akpm, gary, ljs, arnd, gregkh, masahiroy, ojeda, corbet,
qingfang.deng, linux-kernel, rust-for-linux, linux-doc,
linux-kbuild
In-Reply-To: <4579a61db0975b967e8063661be77bb439283fd7@intel.com>
On 5/11/26 10:57, Jani Nikula wrote:
>> scripts/kconfirm/LICENSE | 339 +++++++++
> Why?
>
> See LICENSES/preferred/GPL-2.0.
Sorry, that's an accidental artifact of the tool's current setup as an
open source repo on GitHub. The tool code itself has the expected SPDX
identifiers. I think I need to write a small script for preparing these
patch set submissions. Thanks for your attention on these RFCs.
- Julian Braha
^ permalink raw reply
* Re: [PATCH v10 7/9] gpio: Remove unused `chip` and `srcu` in struct gpio_device
From: Bartosz Golaszewski @ 2026-05-11 13:18 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: Benson Leung, linux-kernel, chrome-platform, driver-core,
linux-doc, linux-gpio, Rafael J. Wysocki, Danilo Krummrich,
Jonathan Corbet, Shuah Khan, Laurent Pinchart, Wolfram Sang,
Jason Gunthorpe, Johan Hovold, Paul E . McKenney, Arnd Bergmann,
Greg Kroah-Hartman, Bartosz Golaszewski, Linus Walleij
In-Reply-To: <20260508105448.31799-8-tzungbi@kernel.org>
On Fri, 8 May 2026 12:54:46 +0200, Tzung-Bi Shih <tzungbi@kernel.org> said:
> `chip` and `srcu` in struct gpio_device are unused as their usages are
> replaced to use revocable. Remove them.
>
> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
> ---
I'm thinking that all the GPIO patches could actually be squashed into one. Is
there any technical reason for the split or is it just for easier review?
Bart
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox