NMIs are blocked by default agter entering SMM.
"Kevin O'Connor" kevin@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