On Tue, May 13, 2014 at 03:27:30PM +0100, David Woodhouse wrote:
On Thu, 2014-04-24 at 22:02 -0400, Kevin O'Connor
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.
That is interesting. Do you have a link to code or a spec handy? (I
looked through the "Compatibility Support Module Specification" again
and I see it talks about SMMs, but it seems to say that what is
implemented is "IBV" specific.)
I have some SMI code for QEMU TCG at:
it's raw, but the basic idea is to implement the same logic in
stacks.c:call32() and romlayout.S:trampoline32() except by using an
SMI instead of the normal method of entering protected mode. That is,
the high level goal is to provide a function that can be called from
SeaBIOS 16bit C code which can run a SeaBIOS 32bit C function.
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).
One of my sub-goals with moving the drivers to 32bit mode is to make a
more clear separation between all the legacy interface code and the
hardware driver code. It sounds like such a separation would also
help with what you describe above. That said, I'm skeptical lots more
interaction with UEFI is a solution. :-)