[SeaBIOS] ohci bulk?

[H. Peter Anvin]

NMIs are blocked by default agter entering SMM.

"Kevin O'Connor" <kevin at koconnor.net> wrote:

>On Fri, Nov 19, 2010 at 03:39:58PM -0800, H. Peter Anvin wrote:
>> On 11/19/2010 02:58 PM, Gerd Hoffmann wrote:
>> > On 09/23/10 14:56, Kevin O'Connor wrote:
>> > 
>> >> I suppose one could write a simple SMI handler that just set the
>OHCI
>> >> cmdstatus bits.  That probably wouldn't be too hard and it
>wouldn't be
>> >> too complex.
>> > 
>> >    Hi folks,
>> > 
>> > What is the current state of affairs?  Sooner or later we'll need a
>
>> > solution for the pci-bar-access-from-real-mode issue ...
>> > 
>> > I looked briefly at the usb3 specs and I think it is impossible to
>drive 
>> > a xHCI adapter without access to the PCI bar.
>
>Looking briefly myself, it does look like accessing the doorbell
>registers will be necessary.
>
>> > Also AHCI support needs access to the PCI bar to submit commands
>and 
>> > check status.
>
>Yeah - it looks that way to me as well.
>
>> 
>> Would INT 15h, AH=87h do the job well enough?  Otherwise it's
>probably
>> SMM or bust...
>
>I don't think int1587 would work reliably.  So, I'd say SMM would be
>needed.
>
>I suppose one could implement a simple SMM gateway - write a magic IO
>bit to invoke the SMM handler, have the SMM handler backup the cpu
>state somewhere in BIOS owned memory, and then leave SMM mode with
>execution at a BIOS handler running in 32bit flat mode.  The BIOS
>handler could then do its work and manually return the CPU to its
>initial state before returning to the guest.  The BIOS would need to
>ensure that it didn't allow interrupts (or NMIs) while in this mode,
>but that's possible.  One would probably want to ensure that the BIOS
>didn't touch any non-BIOS owned memory in this state as well, but
>that's also possible.
>
>-Kevin

-- 
Sent from my mobile phone.  Please pardon any lack of formatting.