Intel FRED Merged For Linux 6.9 As An Important Improvement With Future CPUs

After two years of talking about Intel FRED as Flexible Return and Event Delivery for overhauling how transitions are done between privilege levels (CPU rings), the support code was finally in good shape for merging now with the Linux 6.9 kernel.

Intel FRED is designed to allow for lower latency transitions between privilege levels and for more robust software use. As part of Intel FRED is also the LKGS instruction that was separately already plumbed into the Linux kernel and open-source compilers.

Intel FRED replaces IDT event delivery and a big step forward with future Intel processors supporting FRED. We were expecting to see this code for Linux 6.9 and indeed was submitted for this merge window. Linus Torvalds today went ahead and merged the Intel FRED code without any objections.

The merge sums up the Intel FRED benefits as:

FRED is a replacement for IDT event delivery on x86 and addresses most of the technical nightmares which IDT exposes:

1) Exception cause registers like CR2 need to be manually preserved in nested exception scenarios.

2) Hardware interrupt stack switching is suboptimal for nested exceptions as the interrupt stack mechanism rewinds the stack on each entry which requires a massive effort in the low level entry of #NMI code to handle this.

3) No hardware distinction between entry from kernel or from user which makes establishing kernel context more complex than it needs to be especially for unconditionally nestable exceptions like NMI.

4) NMI nesting caused by IRET unconditionally reenabling NMIs, which is a problem when the perf NMI takes a fault when collecting a stack trace.

5) Partial restore of ESP when returning to a 16-bit segment

6) Limitation of the vector space which can cause vector exhaustion on large systems.

7) Inability to differentiate NMI sources

FRED addresses these shortcomings by:

1) An extended exception stack frame which the CPU uses to save exception cause registers. This ensures that the meta information for each exception is preserved on stack and avoids the extra complexity of preserving it in software.

2) Hardware interrupt stack switching is non-rewinding if a nested exception uses the currently interrupt stack.

3) The entry points for kernel and user context are separate and GS BASE handling which is required to establish kernel context for per CPU variable access is done in hardware.

4) NMIs are now nesting protected. They are only reenabled on the return from NMI.

5) FRED guarantees full restore of ESP

6) FRED does not put a limitation on the vector space by design because it uses a central entry points for kernel and user space and the CPUstores the entry type (exception, trap, interrupt, syscall) on the entry stack along with the vector number. The entry code has to demultiplex this information, but this removes the vector space restriction.

The first hardware implementations will still have the current restricted vector space because lifting this limitation requires further changes to the local APIC.

7) FRED stores the vector number and meta information on stack which allows having more than one NMI vector in future hardware when the required local APIC changes are in place.

The Linux enablement patches mention this Intel FRED support has so far been tested on simulators. As such it doesn't appear FRED will be supported with the likes of upcoming Intel Xeon Granite Rapids / Sierra Forest or Arrow Lake / Lunar Lake processors but like those sometime after these upcoming processors. In any event, it's great seeing this new Intel feature being enabled within the Linux kernel early as is commonly the case for their major features.