[SeaBIOS] ohci bulk?

[Kevin O'Connor]

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.

-Kevin