x86 evolution for segmentation and paging

[Christian Ludloff]

If x86 segmentation and paging do not concern you,
then you can stop reading.

Get a nice cup of tea or coffee. This isn't short.

----------------------- 8< -----------------------

I have been asked to document the x86 behavior for
a PM64-only PML5-only implementation with FRED and
APX that has been used at scale for >1 year.

Background
----------

After more than two decades of x86-64, Legacy Mode
and Compatibility Mode fulfilled their purpose; it
is time to drop the ballast which they pose.

Five years ago Intel published the first FRED spec
and the dust for it settled in late 2023 and early
2024; Intel just shipped their first products with
FRED, and AMD is expected to follow soon. The FRED
cleanup for flexible return and event delivery was
a crucial milestone in the evolution of x86.

Three years ago Intel published the first APX spec
and the first x86S spec. For the APX spec the dust
settled in late 2024 and early 2025; Intel and AMD
are expected to finally ship their products in the
not too distant future. On the other hand, for the
x86S spec, Intel gave up in mid 2024. Which turned
out to be premature. Someone else continued.

Segmentation Extinction
-----------------------

Poof! It's gone! No more selectors or descriptors.

No more ES/CS/SS/DS/FS/GS segment registers and no
more GDTR/IDTR/LDTR/TR table registers. Of course,
no more GDT/IDT/LDT/TSS then, and no more #TS/#NP.

Gone are MOVs from/to segment registers, and PUSH/
POP for FS/GS, and LSS/LFS/LGS. And gone are loads
LGDT/LIDT/LLDT/LTR plus stores SGDT/SIDT/SLDT/STR.

More remnants disappear: LAR/LSL and VERR/VERW and
RETF Iw, RETF, IRET, or CALL/JMP Mp. That's right!
The combo of FRED and x86S laid a nice foundation.

In terms of the stack frames only FRED's survives.
Without a CS.sel or SS.sel, but the rest is there.

Poof! Legacy Mode? Gone! Compatibility Mode? Gone!

Welcome to the great new PM64-only world, at last!

Segmentation Evolution
----------------------

But wait! Aren't FS and GS rather useful features?

Why of course! So... they evolve! The MSRs for FS/
GS base and the {RD,WR}{FS,GS}BASE instructions do
remain. The existing kernel GS base MSR gets a new
sibling: a kernel FS base MSR, at C000_00FFh. (Not
in use today. Conveniently sits before FS/GS/kGS.)

Wait! What? Both kFS and kGS? Why? How? Well, some
scenarios actually benefit from having two pointer
registers instead of only one. And if segmentation
is gone, then FS and GS become simple entries in a
typical register file; think 3-input adder, or use
of a 2nd uop. Mmh, alright... but... what if I...?

Use both? Well, how about flexibility? In the form
of a simple set of config bits in a FSGS_CTRL MSR?
First, 2x2 bits for controlling whether FS/GS gets
swapped by FRED delivery of an event-in-PL3 and by
a FRED return using ERETU back to PL3. (By default
GS gets swapped but FS does not.) Second, a set of
2x2 bits for controlling how FS/GS apply in super-
visor mode and in user mode. (By default, the last
FS or GS wins; other choices are "first one wins",
"both get applied", and "both get ignored".) Done!

Done? Well, one more cleanup item. A segmentation-
free world means that LKGS, just added at the same
time as FRED, disappears again: the need to load a
base address together with segment attributes just
doesn't exist anymore. (That said, legacy x86 CPUs
could add kFS and the FSGS_CTRL MSR, in which case
they would add LKFS at opcode F3h,0Fh,00h,/6 right
next to LKGS at opcode F2h,0Fh,00h,/6. Your call.)

Welcome to the great new PM64-only world of FS/GS!

Paging
------

Hah! Compared to that segmentation extinction act,
paging is really simple. Legacy 2/3/4 level paging
disappears. Poof! It's gone! All that remains then
is 5 level paging, aka PML5. Oh, and yes, finally,
not only with 4 KiB, 2 MiB, 1 GiB pages (at PML1E,
PML2E, PML3E) but also the previously missing ones
i.e. 512 GiB "half tera" or 256 TiB "quarter peta"
pages (at PML4E and PML5E). It's cleaner that way.

That's it for paging? Well, pretty much. But... of
course... there is one more thing. It's small, but
can come in quite handy: PG=0 a.k.a. auto identity
mapping. That is, the core stays in PM64-only, but
instead of page table walks, you automatically get
identity mapped pages (VA=PA). Now, we do not want
to go back there... but sure... think Real Mode to
get the idea. (And just like in classic x86 chips,
an implementation may decide to auto fill or to do
a TLB bypass altogether. The outcome is the same.)

That's it?
----------

Yes. For segmentation and paging, that's it.

Of course there are other areas of x86 cleanup. In
particular, SMM goes away. The decades old "warts"
of interrupt suppression and #DB suppression do go
away. And x86S did put the fixed MTRRs on the "x86
chopping block" too: the 1st MiB isn't so special!

And then there are two more bastions of complexity
that got tackled: machine checks + virtualization.
For those think along the lines of "x86 is nothing
but a guest running on a native non-x86 host -- so
move them where they belong: from x86 to host...".

But... those are topics for some other time.

Recommendations
---------------

Prepare for a great new PM64-only PML5-only world.

Migrate your complexity to x86 software emulation.

Reject x86 cargo cult. And put away the duct tape.

Closure
-------

I have updated https://sandpile.org/ with details.

Look for those orange EXTINCT and EVOLVED markers.

If you have technical followup questions, ping me.

References
----------

[msg 1] 2025-10-14 "x86 opcode/CPUID/MSR allocations"
https://lore.kernel.org/lkml/CAKSQd8WQDfSax83Fyja0Y_aF-jq+7qfOpDo3GU5bz-8wEVUA1A@xxxxxxxxxxxxxx/

[msg 2] 2026-07-27 "x86 AMX/ACE with >8 tiles"
https://lore.kernel.org/lkml/CAKSQd8WxM75DeZvovYXkt2c60ftHeEW_gpf0qTxaLF8i8kjm=w@xxxxxxxxxxxxxx/

[msg 3] 2026-08-28 "x86 WBINVD prefix allocations"
https://lore.kernel.org/lkml/CAKSQd8VBR87Y_VWDZtB+KmHJJg8SYTWu8qY=ZQUFYmNt6TTJMQ@xxxxxxxxxxxxxx/

[FRED] 2025-06-25 "FRED spec" revision 009 -- migrated to SDM revision
090 on 2026-02-05
https://cdrdv2.intel.com/v1/dl/getContent/819481

[APX] 2026-08-25 "APX arch spec" revision 009
https://cdrdv2.intel.com/v1/dl/getContent/784266

[x86S] 2024-06-25 "x86S arch spec" revision 002
https://web.archive.org/web/20241002150150/https://cdrdv2-public.intel.com/776648/x86s-eas-external-1.2.pdf

[SDM] 2026-06-19 "Software Developer's Manual" revision 092
https://cdrdv2.intel.com/v1/dl/getContent/671200

[APM] 2026-07-29 "Architecture Programmer's Manual" revision 3.10
https://docs.amd.com/search/all?query=40332

----------------------- 8< -----------------------

--
C.