[leeter]

So right now when an x86-64 CPU boots it starts in 16bit real mode regardless of everything else. The UEFI then has to set up a x64 protected mode env then the OS picks up from there. If you drop that backwards compat (e.g. 16bit, virtual 8086 mode etc.) you can remove a lot of cruft that is mostly worked around. If nobody is setting Local Descriptor tables then why support it? Or the hardware task switching support that's not even supported in long mode etc.

[zozbot234]

I believe that individual cores must still be brought up via real mode, etc. even when the UEFI boot otherwise gives you a clean 64-bit environment. So the backward compatibility must still be present.

[leeter]

It's complicated and annoying but yes. There is also the question of 'downleveling' a core back to real mode when the others aren't. But if you require UEFI and secure boot then you could bypass that and go to a 64-bit linear reset vector anyway as that's how UEFI sets up the boot env. That would mean you'd only need to initialize that core and it'\s local APIC and associated envs in theory instead of playing mode hopscotch.

On the topic of downleveling... based on the research I've done (think writing a UEFI capable kernel for FreeDOS) it's dubious at best to do that because the real mode core wouldn't know about the local APIC and would mess with the IO APIC when you really really don't want it to. So is it possible? Potentially? Would anyone with any shred of sanity recommend it? No not in my opinion. There is no valid reason to do that.