4 ms·
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
by zaarn 8y ago
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.
- nsajko 8y agoWhat if you have a UEFI motherboard with a BIOS bootloader like Syslinux?
- jjoonathan 8y agoDoes 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 8y agoUEFI starts the same way but yeah, it hands off 64bit (or 32bit if you have a 32bit UEFI).
- tenebrisalietum 8y ago"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 8y agoTo 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.