[SeaBIOS] ohci bulk?
H. Peter Anvin
hpa at zytor.com
Thu Sep 23 03:33:46 CEST 2010
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
> 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.
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.
> 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.
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
More information about the SeaBIOS