On Wed, Sep 22, 2010 at 01:08:07PM -0700, H. Peter Anvin wrote:
On 09/22/2010 11:21 AM, H. Peter Anvin wrote:
On 09/22/2010 05:52 AM, Kevin O'Connor wrote:
The BIOS can put the machine in big real mode when it launches the OS, but it can't expect that it will always be called in big real mode. The BIOS could attempt to transition to 32bit mode (or big real mode) in the disk handler, but it may have been called in vm86 mode which would then effectively cause a crash. (It also wipes out the hidden segment registers which may confuse the OS.) Use of vm86 mode is not uncommon - freedos does it and so does (I'm told) Linux.
The standard way to deal with this in the BIOS (and *only* the BIOS can do this!) is to trap into SMM and have an SMI handler do the I/O. Taking an SMI drops the CPU into big real mode regardless of what the previous CPU mode was.
Using SMI is something I've thought a little about. It does have some snags: SMI programming is chipset specific on real hardware so one can't deploy a single solution for all coreboot users; kvm doesn't have SMI support; using an SMI to get out of vm86 mode requires the BIOS to emulate all memory accesses to user memory (manually walking the page table, forcing page faults) which is tricky; there might be subtle security implications with having a BIOS interface that can effectively escalate privileges.
The other option is to enter protected mode for the operation, or, if you detect that you're already in protected mode (which means V86 mode)
I didn't think there was a way for the user code to know it was running in vm86 mode - I thought it appeared just like regular real-mode. One could try to go into protected mode and try to catch the failure, but I'd guess most OSs that run code in vm86 mode would trap and abort in that situation.
then you invoke the INT 15h mover. Not all environments is going to handle the INT 15h mover correctly, though.
Are you referring to INT 0x15 ah=0x89? This can request a transition to protected mode, but I didn't see any equivalent way to get back to real mode.
A related call is INT 0x15 ah=0x87 which does a highmem capable memcpy. Unfortunately this handler does a 16bit memcpy (rep movsw), and the OHCI spec requires the cmdstatus register be accessed with a 32bit memory access.