Documentation/admin-guide/kernel-parameters.txt | 4 ++-- arch/x86/Kconfig | 2 +- arch/x86/kernel/cpu/common.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-)
From: H. Peter Anvin (Intel) <hpa@zytor.com>
When FRED was added to the mainline kernel, it was set up as an
explicit opt-in due to the risk of regressions before hardware was
available publicly.
Now, Panther Lake (Core Ultra 300 series) has been released, and
benchmarking by Phoronix has shown that it provides a significant
performance benefit on most workloads:
https://www.phoronix.com/review/intel-fred-panther-lake
Accordingly, enable FRED by default if the CPU supports it. FRED can
of course still be disabled via the fred=off command line option.
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++--
arch/x86/Kconfig | 2 +-
arch/x86/kernel/cpu/common.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 03a550630644..bfa8a20ccc37 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1750,8 +1750,8 @@ Kernel parameters
fred= [X86-64]
Enable/disable Flexible Return and Event Delivery.
Format: { on | off }
- on: enable FRED when it's present.
- off: disable FRED, the default setting.
+ on: enable FRED when it's present, the default setting.
+ off: disable FRED.
ftrace=[tracer]
[FTRACE] will set and start the specified tracer
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e2df1b147184..876b663dcf38 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -557,7 +557,7 @@ config X86_FRED
bool "Flexible Return and Event Delivery"
depends on X86_64
help
- When enabled, try to use Flexible Return and Event Delivery
+ When enabled, use Flexible Return and Event Delivery
instead of the legacy SYSCALL/SYSENTER/IDT architecture for
ring transitions and exception/interrupt handling if the
system supports it.
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a8ff4376c286..e22a49869380 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1746,7 +1746,7 @@ static void __init cpu_parse_early_param(void)
/* Minimize the gap between FRED is available and available but disabled. */
arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg));
- if (arglen != 2 || strncmp(arg, "on", 2))
+ if (arglen > 0 && (arglen != 2 || strncmp(arg, "on", 2)))
setup_clear_cpu_cap(X86_FEATURE_FRED);
arglen = cmdline_find_option(boot_command_line, "clearcpuid", arg, sizeof(arg));On 3/23/2026 1:15 PM, H. Peter Anvin wrote:
Can we please include this as well?
diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c
index e736b19e18de..117aa06d25ca 100644
--- a/arch/x86/kernel/fred.c
+++ b/arch/x86/kernel/fred.c
@@ -27,9 +27,6 @@ EXPORT_PER_CPU_SYMBOL(fred_rsp0);
void cpu_init_fred_exceptions(void)
{
- /* When FRED is enabled by default, remove this log message */
- pr_info("Initialize FRED on CPU%d\n", smp_processor_id());
-
/*
* If a kernel event is delivered before a CPU goes to user level for
* the first time, its SS is NULL thus NULL is pushed into the SS field
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 03a550630644..bfa8a20ccc37 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1750,8 +1750,8 @@ Kernel parameters
> fred= [X86-64]
> Enable/disable Flexible Return and Event Delivery.
> Format: { on | off }
> - on: enable FRED when it's present.
> - off: disable FRED, the default setting.
> + on: enable FRED when it's present, the default setting.
Why do we need the fred=on line after this series? It can't really
enable FRED when the compile option is disabled. Seems like a dead (and
slightly confusing) option to me.
> + off: disable FRED.
>
> ftrace=[tracer]
> [FTRACE] will set and start the specified tracer
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index e2df1b147184..876b663dcf38 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -557,7 +557,7 @@ config X86_FRED
> bool "Flexible Return and Event Delivery"
> depends on X86_64
> help
> - When enabled, try to use Flexible Return and Event Delivery
> + When enabled, use Flexible Return and Event Delivery
> instead of the legacy SYSCALL/SYSENTER/IDT architecture for
> ring transitions and exception/interrupt handling if the
> system supports it.
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index a8ff4376c286..e22a49869380 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1746,7 +1746,7 @@ static void __init cpu_parse_early_param(void)
>
> /* Minimize the gap between FRED is available and available but disabled. */
> arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg));
> - if (arglen != 2 || strncmp(arg, "on", 2))
> + if (arglen > 0 && (arglen != 2 || strncmp(arg, "on", 2)))
> setup_clear_cpu_cap(X86_FEATURE_FRED);
Nit: Would it be better to compare with "off" rather than not on?
>
> arglen = cmdline_find_option(boot_command_line, "clearcpuid", arg, sizeof(arg));
On Mon, Mar 23, 2026 at 06:01:09PM -0700, Sohil Mehta wrote:
> On 3/23/2026 1:15 PM, H. Peter Anvin wrote:
>
> Can we please include this as well?
>
> diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c
> index e736b19e18de..117aa06d25ca 100644
> --- a/arch/x86/kernel/fred.c
> +++ b/arch/x86/kernel/fred.c
> @@ -27,9 +27,6 @@ EXPORT_PER_CPU_SYMBOL(fred_rsp0);
>
> void cpu_init_fred_exceptions(void)
> {
> - /* When FRED is enabled by default, remove this log message */
> - pr_info("Initialize FRED on CPU%d\n", smp_processor_id());
> -
> /*
> * If a kernel event is delivered before a CPU goes to user level for
> * the first time, its SS is NULL thus NULL is pushed into the SS field
Yes please. This looks like some early bringup leftover.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
> On Mar 23, 2026, at 6:01 PM, Sohil Mehta <sohil.mehta@intel.com> wrote: > >> @@ -1746,7 +1746,7 @@ static void __init cpu_parse_early_param(void) >> >> /* Minimize the gap between FRED is available and available but disabled. */ >> arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg)); >> - if (arglen != 2 || strncmp(arg, "on", 2)) >> + if (arglen > 0 && (arglen != 2 || strncmp(arg, "on", 2))) >> setup_clear_cpu_cap(X86_FEATURE_FRED); > > Nit: Would it be better to compare with "off" rather than not on? +1 :)
On 2026-03-23 20:05, Xin Li wrote: > > >> On Mar 23, 2026, at 6:01 PM, Sohil Mehta <sohil.mehta@intel.com> wrote: >> >>> @@ -1746,7 +1746,7 @@ static void __init cpu_parse_early_param(void) >>> >>> /* Minimize the gap between FRED is available and available but disabled. */ >>> arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg)); >>> - if (arglen != 2 || strncmp(arg, "on", 2)) >>> + if (arglen > 0 && (arglen != 2 || strncmp(arg, "on", 2))) >>> setup_clear_cpu_cap(X86_FEATURE_FRED); >> >> Nit: Would it be better to compare with "off" rather than not on? > > +1 :) > It would change the meaning of something like "fred=0" though. -hpa
On 3/23/2026 8:52 PM, H. Peter Anvin wrote: >>> Nit: Would it be better to compare with "off" rather than not on? >> >> +1 :) >> > > It would change the meaning of something like "fred=0" though. > I don't believe we have ever supported fred=0 or fred=1, did we? Also, I am not sure about letting userspace be creative with command line parameters :) For example, fred=yes and fred=enable will both pass the same check and cause FRED to be disabled.
On March 23, 2026 10:08:42 PM PDT, Sohil Mehta <sohil.mehta@intel.com> wrote: >On 3/23/2026 8:52 PM, H. Peter Anvin wrote: >>>> Nit: Would it be better to compare with "off" rather than not on? >>> >>> +1 :) >>> >> >> It would change the meaning of something like "fred=0" though. >> > >I don't believe we have ever supported fred=0 or fred=1, did we? > >Also, I am not sure about letting userspace be creative with command >line parameters :) For example, fred=yes and fred=enable will both pass >the same check and cause FRED to be disabled. Unfortunately right now we *are* being creative: anytime but the exact string "on" disables FRED. This is a general problem. In the kernel; overall I feel promoting foo= syntax for booleans, which was not the original style, was a mistake, but here we are. Anyway, I don't have a strong preference and I think we can leave that policy decision to the maintainers.
On 3/24/2026 12:50 AM, H. Peter Anvin wrote: Giving it one last try if I can change your mind :) > On March 23, 2026 10:08:42 PM PDT, Sohil Mehta <sohil.mehta@intel.com> wrote: >> On 3/23/2026 8:52 PM, H. Peter Anvin wrote: >>>>> Nit: Would it be better to compare with "off" rather than not on? >>>> >>>> +1 :) >>>> >>> >>> It would change the meaning of something like "fred=0" though. >>> >> >> I don't believe we have ever supported fred=0 or fred=1, did we? >> >> Also, I am not sure about letting userspace be creative with command >> line parameters :) For example, fred=yes and fred=enable will both pass >> the same check and cause FRED to be disabled. > > Unfortunately right now we *are* being creative: anytime but the exact string "on" disables FRED. You are right, we are accepting invalid inputs today. There is a slight difference though. The default right now is FRED disabled. So any invalid input would not change the kernel default. Only fred=on enables the feature. With FRED proposed to be default on, I think we should match the above and only let fred=off disable it. All other inputs should be ignored. > This is a general problem. I agree. In general, we shouldn't even need special command line parameters to *disable* features. clearcpuid=fred would have been equivalent to fred=off if it didn't taint the kernel. I don't know the exact history about why the taint is needed. > In the kernel; overall I feel promoting foo= syntax for booleans, which was not the original style, was a mistake, but here we are. > > Anyway, I don't have a strong preference and I think we can leave that policy decision to the maintainers. > Yes, that's completely fine with me. I won't push for it any further.
On Tue, Mar 24, 2026 at 10:19:00AM -0700, Sohil Mehta wrote:
> With FRED proposed to be default on, I think we should match the above
> and only let fred=off disable it. All other inputs should be ignored.
So we have only said so far that "on" enables FRED and "off" disables it. And
we can do that by carving out the FRED option parsing into a separate function
and acting only on those and ignoring the rest.
All those other fred=X things should simply be ignored.
> I agree. In general, we shouldn't even need special command line
> parameters to *disable* features. clearcpuid=fred would have been
> equivalent to fred=off if it didn't taint the kernel. I don't know the
> exact history about why the taint is needed.
Because you should not poke at clearing CPUID features unless you know what
you're doing and this cmdline option should not exist at all. But we have it
so...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 2026-03-24 12:53, Borislav Petkov wrote: > On Tue, Mar 24, 2026 at 10:19:00AM -0700, Sohil Mehta wrote: >> With FRED proposed to be default on, I think we should match the above >> and only let fred=off disable it. All other inputs should be ignored. > > So we have only said so far that "on" enables FRED and "off" disables it. And > we can do that by carving out the FRED option parsing into a separate function > and acting only on those and ignoring the rest. > > All those other fred=X things should simply be ignored. > Well, that's easy. I just didn't want to change existing behavior. If that is your policy decision then I'm fine with that. We don't even need a new function; it is actually an even smaller change to the code than this patchset version, so I'll rev the patchset. It WOULD be good to have a global function to parse boolean arguments in a kernel-coherent manner, but that is out of scope for this patchset. >> I agree. In general, we shouldn't even need special command line >> parameters to *disable* features. clearcpuid=fred would have been >> equivalent to fred=off if it didn't taint the kernel. I don't know the >> exact history about why the taint is needed. > > Because you should not poke at clearing CPUID features unless you know what > you're doing and this cmdline option should not exist at all. But we have it > so... > Well, it is useful for testing code paths for legacy hardware. -hpa
On Wed, Mar 25, 2026 at 09:22:35AM -0700, H. Peter Anvin wrote:
> Well, that's easy. I just didn't want to change existing behavior. If that is
> your policy decision then I'm fine with that.
>
> We don't even need a new function; it is actually an even smaller change to
> the code than this patchset version, so I'll rev the patchset.
>
> It WOULD be good to have a global function to parse boolean arguments in a
> kernel-coherent manner, but that is out of scope for this patchset.
Right.
> > Because you should not poke at clearing CPUID features unless you know what
> > you're doing and this cmdline option should not exist at all. But we have it
> > so...
> >
>
> Well, it is useful for testing code paths for legacy hardware.
... which would presume you know what you're doing.
clearcpuid= is not something you or I or anyone else wants to debug when
people start clearing random CPUID bits without knowing any better.
Thus the tainting.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 3/25/2026 9:30 AM, Borislav Petkov wrote: >>> Because you should not poke at clearing CPUID features unless you know what >>> you're doing and this cmdline option should not exist at all. But we have it >>> so... >>> >> >> Well, it is useful for testing code paths for legacy hardware. > > ... which would presume you know what you're doing. > > clearcpuid= is not something you or I or anyone else wants to debug when > people start clearing random CPUID bits without knowing any better. > > Thus the tainting. > Makes sense. Thanks for the insight.
On 2026-03-25 09:30, Borislav Petkov wrote: >> >> Well, it is useful for testing code paths for legacy hardware. > > ... which would presume you know what you're doing. > > clearcpuid= is not something you or I or anyone else wants to debug when > people start clearing random CPUID bits without knowing any better. > > Thus the tainting. > Exactly. -hpa
On 3/23/2026 10:08 PM, Sohil Mehta wrote: > On 3/23/2026 8:52 PM, H. Peter Anvin wrote: >>>> Nit: Would it be better to compare with "off" rather than not on? >>> >>> +1 :) >>> >> >> It would change the meaning of something like "fred=0" though. >> > > I don't believe we have ever supported fred=0 or fred=1, did we? > > Also, I am not sure about letting userspace be creative with command s/userspace/users > line parameters :) For example, fred=yes and fred=enable will both pass > the same check and cause FRED to be disabled.
On Mon, Mar 23, 2026 at 01:15:03PM -0700, H. Peter Anvin wrote: > From: H. Peter Anvin (Intel) <hpa@zytor.com> > > When FRED was added to the mainline kernel, it was set up as an > explicit opt-in due to the risk of regressions before hardware was > available publicly. > > Now, Panther Lake (Core Ultra 300 series) has been released, and > benchmarking by Phoronix has shown that it provides a significant > performance benefit on most workloads: > > https://www.phoronix.com/review/intel-fred-panther-lake > > Accordingly, enable FRED by default if the CPU supports it. FRED can > of course still be disabled via the fred=off command line option. Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
When FRED was added to the mainline kernel, it was set up as an
explicit opt-in due to the risk of regressions before hardware was
available publicly.
Now, Panther Lake (Core Ultra 300 series) has been released, and
benchmarking by Phoronix has shown that it provides a significant
performance benefit on most workloads:
https://www.phoronix.com/review/intel-fred-panther-lake
Accordingly, enable FRED by default if the CPU supports it. FRED can
of course still be disabled via the fred=off command line option.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++--
arch/x86/kernel/cpu/common.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 03a550630644..bfa8a20ccc37 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1750,8 +1750,8 @@ Kernel parameters
fred= [X86-64]
Enable/disable Flexible Return and Event Delivery.
Format: { on | off }
- on: enable FRED when it's present.
- off: disable FRED, the default setting.
+ on: enable FRED when it's present, the default setting.
+ off: disable FRED.
ftrace=[tracer]
[FTRACE] will set and start the specified tracer
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index a8ff4376c286..e22a49869380 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1746,7 +1746,7 @@ static void __init cpu_parse_early_param(void)
/* Minimize the gap between FRED is available and available but disabled. */
arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg));
- if (arglen != 2 || strncmp(arg, "on", 2))
+ if (arglen > 0 && (arglen != 2 || strncmp(arg, "on", 2)))
setup_clear_cpu_cap(X86_FEATURE_FRED);
arglen = cmdline_find_option(boot_command_line, "clearcpuid", arg, sizeof(arg));
--
2.53.0The CONFIG_X86_FRED help text has both "try to" and "if the system
supports it", which are redundant statements.
Remove "try to".
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e2df1b147184..876b663dcf38 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -557,7 +557,7 @@ config X86_FRED
bool "Flexible Return and Event Delivery"
depends on X86_64
help
- When enabled, try to use Flexible Return and Event Delivery
+ When enabled, use Flexible Return and Event Delivery
instead of the legacy SYSCALL/SYSENTER/IDT architecture for
ring transitions and exception/interrupt handling if the
system supports it.
--
2.53.0© 2016 - 2026 Red Hat, Inc.