[zaarn]

If you're on UEFI, the 16bit environment is very likely running inside a UEFI "hypervisor" (ie, it puts the CPU into 16bit mode after setting up the appropriate interrupt handlers and hardware drivers). If you boot Windows or Linux via UEFI and not BIOS methods, then you never leave 64bit mode during boot.

Real BIOS that boots from 16bit is quite a rarity these days.

[tenebrisalietum]

"Running inside a hypervisor" is not equivalent to the UEFI setting interrupt vectors to point to its own code.

Not sure how UEFI's "Compatibility Service Module" works exactly but if it acts like the original BIOS did, it's just a chunk of code that can be called, either by a program or be set as the destination for interrupts.

But there is no "VM exit" mechanism like there is in hypervisors. One thing a hypervisor does is intercept IO address accesses and does them on behalf of the client code (without the code knowing), don't think the CSM is doing this.

[zaarn]

To my knowledge, UEFI does sorta do hypervisor-y things when running a 16bit bootloader since the GPU needs to be operated from 64bit ( via it's UEFI driver) and keyboard and mouse need to be emulated via UEFI drivers, which are also 64bit. That is unless the device has a CSM module and can run natively 16bit code during CSM boot, which not all devices can do.

[jjoonathan]

Does UEFI start the same way as BIOS (firmware on LPC bus, PC starts at 0xFFFFFFF0)? Or is there a different top level mechanism?

My understanding was that the CPU still starts in 16 bit real mode (with an evil hack to sign-extend IP) but that by the time UEFI hands off to code on a hard drive it is in long mode.

[zaarn]

UEFI starts the same way but yeah, it hands off 64bit (or 32bit if you have a 32bit UEFI).

[nsajko]

What if you have a UEFI motherboard with a BIOS bootloader like Syslinux?