FRED is now believed to be complete for AMD systems, and has had its tyres
kicked by both XenServer and AMD. Enable FRED by default on capable AMD
systems (Zen6 and later).
Support on Intel is still not yet complete. Leave it as tech preview and not
security supported.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Teddy Astie <teddy.astie@vates.tech>
CC: Oleksii Kurochko <oleksii.kurochko@gmail.com>
The issue on Intel is to do with virtualisation of MSR_SPEC_CTRL for PV
guests, and is waiting on the resolution of a question I've asked Intel.
---
docs/misc/xen-command-line.pandoc | 6 +++---
xen/arch/x86/traps-setup.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index ef3c7371895b..50c119e5b79f 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1259,12 +1259,12 @@ does not provide `VM_ENTRY_LOAD_GUEST_PAT`.
### fred (x86)
> `= <bool>`
-> Default: `false`
+> Default: `true` on AMD, `false` otherwise
Flexible Return and Event Delivery is an overhaul of interrupt, exception and
system call handling, fixing many corner cases in the x86 architecture, and
-expected in hardware from 2025. Support in Xen is a work in progress and
-disabled by default.
+expected in hardware from 2026. FRED is fully supported on AMD hardware.
+Intel hardware is still tech preview and not security supported.
### gnttab
> `= List of [ max-ver:<integer>, transitive=<bool>, transfer=<bool> ]`
diff --git a/xen/arch/x86/traps-setup.c b/xen/arch/x86/traps-setup.c
index ccbd53fd9db0..a79a3b201389 100644
--- a/xen/arch/x86/traps-setup.c
+++ b/xen/arch/x86/traps-setup.c
@@ -22,7 +22,7 @@ unsigned int __ro_after_init ler_msr;
static bool __initdata opt_ler;
boolean_param("ler", opt_ler);
-int8_t __ro_after_init opt_fred = 0;
+int8_t __ro_after_init opt_fred = -1;
boolean_param("fred", opt_fred);
void nocall entry_PF(void);
@@ -392,7 +392,7 @@ void __init traps_init(void)
}
if ( opt_fred == -1 )
- opt_fred = !pv_shim;
+ opt_fred = (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && !pv_shim;
if ( opt_fred )
{
--
2.39.5
On 02.06.2026 18:45, Andrew Cooper wrote: > FRED is now believed to be complete for AMD systems, and has had its tyres > kicked by both XenServer and AMD. Enable FRED by default on capable AMD > systems (Zen6 and later). > > Support on Intel is still not yet complete. Leave it as tech preview and not > security supported. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> with one remark: > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -1259,12 +1259,12 @@ does not provide `VM_ENTRY_LOAD_GUEST_PAT`. > ### fred (x86) > > `= <bool>` > > -> Default: `false` > +> Default: `true` on AMD, `false` otherwise > > Flexible Return and Event Delivery is an overhaul of interrupt, exception and > system call handling, fixing many corner cases in the x86 architecture, and > -expected in hardware from 2025. Support in Xen is a work in progress and > -disabled by default. > +expected in hardware from 2026. FRED is fully supported on AMD hardware. > +Intel hardware is still tech preview and not security supported. Is having "security" here really appropriate? There's a functional issue to be sorted. That's expressed by "tech preview", yes, but it still feels somewhat odd. If you want to keep the word, may I suggest to insert "in particular"? May I further suggest "On Intel hardware it is ..."? Jan
On 03/06/2026 7:27 am, Jan Beulich wrote: > On 02.06.2026 18:45, Andrew Cooper wrote: >> FRED is now believed to be complete for AMD systems, and has had its tyres >> kicked by both XenServer and AMD. Enable FRED by default on capable AMD >> systems (Zen6 and later). >> >> Support on Intel is still not yet complete. Leave it as tech preview and not >> security supported. >> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > Acked-by: Jan Beulich <jbeulich@suse.com> > with one remark: > >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -1259,12 +1259,12 @@ does not provide `VM_ENTRY_LOAD_GUEST_PAT`. >> ### fred (x86) >> > `= <bool>` >> >> -> Default: `false` >> +> Default: `true` on AMD, `false` otherwise >> >> Flexible Return and Event Delivery is an overhaul of interrupt, exception and >> system call handling, fixing many corner cases in the x86 architecture, and >> -expected in hardware from 2025. Support in Xen is a work in progress and >> -disabled by default. >> +expected in hardware from 2026. FRED is fully supported on AMD hardware. Along with the year, I suppose I should name the CPUs specifically now that they're public. >> +Intel hardware is still tech preview and not security supported. > Is having "security" here really appropriate? There's a functional issue to be > sorted. That's expressed by "tech preview", yes, but it still feels somewhat > odd. If you want to keep the word, may I suggest to insert "in particular"? I was just trying to make things clearer. One of the common audience groups for this file is not liable to know Xen's precise definitions of experimental/tech-preview/supported. > May I further suggest "On Intel hardware it is ..."? How does this look? diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index ef3c7371895b..ff6d08affb63 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1259,12 +1259,13 @@ does not provide `VM_ENTRY_LOAD_GUEST_PAT`. ### fred (x86) > `= <bool>` -> Default: `false` +> Default: `true` on AMD, `false` otherwise Flexible Return and Event Delivery is an overhaul of interrupt, exception and -system call handling, fixing many corner cases in the x86 architecture, and -expected in hardware from 2025. Support in Xen is a work in progress and -disabled by default. +system call handling, fixing many corner cases in the x86 architecture, and is +available on Intel Panther Lake and Diamond Rapids CPUs, and AMD Zen6 CPUs. +FRED is fully supported on AMD hardware. On Intel hardware it is still tech +preview, and in particular not security supported. ### gnttab > `= List of [ max-ver:<integer>, transitive=<bool>, transfer=<bool> ]` ? ~Andrew
On 03.06.2026 11:36, Andrew Cooper wrote: > On 03/06/2026 7:27 am, Jan Beulich wrote: >> On 02.06.2026 18:45, Andrew Cooper wrote: >>> FRED is now believed to be complete for AMD systems, and has had its tyres >>> kicked by both XenServer and AMD. Enable FRED by default on capable AMD >>> systems (Zen6 and later). >>> >>> Support on Intel is still not yet complete. Leave it as tech preview and not >>> security supported. >>> >>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> >> Acked-by: Jan Beulich <jbeulich@suse.com> >> with one remark: >> >>> --- a/docs/misc/xen-command-line.pandoc >>> +++ b/docs/misc/xen-command-line.pandoc >>> @@ -1259,12 +1259,12 @@ does not provide `VM_ENTRY_LOAD_GUEST_PAT`. >>> ### fred (x86) >>> > `= <bool>` >>> >>> -> Default: `false` >>> +> Default: `true` on AMD, `false` otherwise >>> >>> Flexible Return and Event Delivery is an overhaul of interrupt, exception and >>> system call handling, fixing many corner cases in the x86 architecture, and >>> -expected in hardware from 2025. Support in Xen is a work in progress and >>> -disabled by default. >>> +expected in hardware from 2026. FRED is fully supported on AMD hardware. > > Along with the year, I suppose I should name the CPUs specifically now > that they're public. > >>> +Intel hardware is still tech preview and not security supported. >> Is having "security" here really appropriate? There's a functional issue to be >> sorted. That's expressed by "tech preview", yes, but it still feels somewhat >> odd. If you want to keep the word, may I suggest to insert "in particular"? > > I was just trying to make things clearer. One of the common audience > groups for this file is not liable to know Xen's precise definitions of > experimental/tech-preview/supported. > >> May I further suggest "On Intel hardware it is ..."? > > How does this look? > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > index ef3c7371895b..ff6d08affb63 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -1259,12 +1259,13 @@ does not provide `VM_ENTRY_LOAD_GUEST_PAT`. > ### fred (x86) > > `= <bool>` > > -> Default: `false` > +> Default: `true` on AMD, `false` otherwise > > Flexible Return and Event Delivery is an overhaul of interrupt, exception and > -system call handling, fixing many corner cases in the x86 architecture, and > -expected in hardware from 2025. Support in Xen is a work in progress and > -disabled by default. > +system call handling, fixing many corner cases in the x86 architecture, and is > +available on Intel Panther Lake and Diamond Rapids CPUs, and AMD Zen6 CPUs. > +FRED is fully supported on AMD hardware. On Intel hardware it is still tech > +preview, and in particular not security supported. > > ### gnttab > > `= List of [ max-ver:<integer>, transitive=<bool>, transfer=<bool> ]` > > > ? Looks good, thanks. Jan
On 6/2/26 6:45 PM, Andrew Cooper wrote: > FRED is now believed to be complete for AMD systems, and has had its tyres > kicked by both XenServer and AMD. Enable FRED by default on capable AMD > systems (Zen6 and later). > > Support on Intel is still not yet complete. Leave it as tech preview and not > security supported. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > --- > CC: Jan Beulich <jbeulich@suse.com> > CC: Roger Pau Monné <roger.pau@citrix.com> > CC: Teddy Astie <teddy.astie@vates.tech> > CC: Oleksii Kurochko <oleksii.kurochko@gmail.com> Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> > > The issue on Intel is to do with virtualisation of MSR_SPEC_CTRL for PV > guests, and is waiting on the resolution of a question I've asked Intel. > --- > docs/misc/xen-command-line.pandoc | 6 +++--- > xen/arch/x86/traps-setup.c | 4 ++-- > 2 files changed, 5 insertions(+), 5 deletions(-) > Don't we want than add that to CHANGELOG.md that FRED is now enabled by default? Thanks. ~ Oleksii
On 02/06/2026 8:21 pm, Oleksii Kurochko wrote: > > > On 6/2/26 6:45 PM, Andrew Cooper wrote: >> FRED is now believed to be complete for AMD systems, and has had its >> tyres >> kicked by both XenServer and AMD. Enable FRED by default on capable AMD >> systems (Zen6 and later). >> >> Support on Intel is still not yet complete. Leave it as tech preview >> and not >> security supported. >> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> >> --- >> CC: Jan Beulich <jbeulich@suse.com> >> CC: Roger Pau Monné <roger.pau@citrix.com> >> CC: Teddy Astie <teddy.astie@vates.tech> >> CC: Oleksii Kurochko <oleksii.kurochko@gmail.com> > > Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> > Thanks. >> >> The issue on Intel is to do with virtualisation of MSR_SPEC_CTRL for PV >> guests, and is waiting on the resolution of a question I've asked Intel. >> --- >> docs/misc/xen-command-line.pandoc | 6 +++--- >> xen/arch/x86/traps-setup.c | 4 ++-- >> 2 files changed, 5 insertions(+), 5 deletions(-) >> > > Don't we want than add that to CHANGELOG.md that FRED is now enabled > by default? I was going to wait until we had sorted Intel before doing that. But there's no chance of that happening for 4.22 now. ~Andrew
© 2016 - 2026 Red Hat, Inc.