On Thu, 2014-04-24 at 22:02 -0400, Kevin O'Connor wrote:
I've been considering a possible architectural change to SeaBIOS. Currently, SeaBIOS contains a mix of 16bit code and 32bit code. All of the initialization and bootup code is done in regular 32bit mode, but runtime code (the callbacks the OS uses) is generally run in 16bit mode. I have been thinking about possibly changing this so that hardware driver code runs exclusively in 32bit mode.
The biggest downside to this change would be problems running old DOS era programs that attempt to run the BIOS in vm86 mode. Specifically, the dos emm386 program is known to prevent 32 bit trampolines in SeaBIOS from working. (There's been a bit of experience with AHCI drivers running in 32bit mode (and now XHCI) so we have good confidence that modern OSes wont present a problem.) To continue to support these old DOS era programs I'm proposing we implement an SMI to help trampoline to 32bit mode.
This sounds broadly similar to the approach taken by some CSM implementations. Instead of having native device drivers in the CSM and actually taking over the hardware as SeaBIOS does, they use SMI to trampoline back into UEFI-side code and use the drivers there.
If we're going to do this, it would be interesting to see if we can use the same protocol — both for thunking from 16-bit to 32-bit SeaBIOS code, and for thunking from the SeaBIOS CSM to OVMF/UEFI.
Using the native UEFI drivers via such a thunk would resolve a number of the issues around who owns the hardware, and how we continue with a UEFI boot after a 'Legacy' boot attempt has failed (to detect the 0x55aa signature on a boot sector, for example).