[SeaBIOS] ohci bulk?

[H. Peter Anvin]

On 09/22/2010 06:16 PM, Kevin O'Connor wrote:
> 
> 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;

Right so far, althoguh SMI is pretty easy to implement.

> 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;

Actually you can switch to protected mode and turn the page tables on if
you want.

> there might be
> subtle security implications with having a BIOS interface that can
> effectively escalate privileges.

Yes.
 
>> 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.

No, the SMSW instruction can be used to distinguish protected mode and
therefore V86 mode.

>> 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.

No, AH=0x87.

> 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.

That might be a problem if that is actually done that way (which it
generally won't.)  Still, you do have the issue of what happens in a V86
environment if it doesn't just pass code to the original BIOS.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.