usb keyboard vs btx: an SMI theory
- From: Andriy Gapon <avg@xxxxxxxxxxx>
- Date: Tue, 16 Dec 2008 15:16:44 +0200
I am not a close-to-hardware guy, my knowledge of IA32 architecture and
IA32 assembly is very (very!) limited, so my reasoning can have some
glaring flaws. Also, I am quite fuzzy on the details of btx workings and
some other aspects.
Still I have a theory (or a "gut feeling") about the bad interaction
between "newer" loader and USB keyboard that I experienced. I believe
that a number other people had the same or similar issues.
It seems that i386 btx code contains routines, intx31/int_hw +
rret_tramp, to enter real mode, execute an interrupt handler and exit
real mode. It seems that this code can be invoked in two cases: (1) when
protected code wishes to execute a BIOS int function and calls into btx
via int 31h; (2) when a hardware interrupt happens while in protected mode.
It also looks that the routine saves and restores certain context before
entering and after exiting real mode. This is done in a special fixed
memory location (MEM_ESPR). This memory lcoation also seems to be used
as a stack base address for real mode.
Normally there can not be any shared/overlapping access to that
location. This is because in all cases interrupts are disabled and
machine is supposed to be uniprocessor mode still.
Now lets look at the other end - "USB legacy support". I think that BIOS
emulates PS/2 keyboard for real USB keyboard in the following way.
When a key is pressed a USB event is generated by the keyboard.
USB host controller generates an SMI upon the USB event.
SMM code checks if SMI was generated by USB, performs necessary USB
chores and then pretends as if the key press was made on an PS/2 keyboard.
This is something that I am very fuzzy about, but I think that SMM code
somehow invokes IRQ 1 handler.
And I think that because SMI is not maskable it can be "nested" inside
any other interrupt (software or hardware) and it is possible that IRQ1
handler for protected mode can be executed (and thus int_hw) while we
were already executing int_hw for some other reason - a "system call"
from protected mode code or hardware interrupt.
In this case the context data stored in memory would get corrupted.
I suspect that what I actually observe looks like interrupts never
getting re-enabled.
Again, I am very fuzzy about the exact details, but I think that this is
something that could be happening and I think that SMI is of primary
interest here. I also think that this might explain to a certain degree
the difference in behavior between "older" btx and "newer" btx.
--
Andriy Gapon
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- Prev by Date: PRINTF_BUFR_SIZE in freebsd6
- Next by Date: Re: PRINTF_BUFR_SIZE in freebsd6
- Previous by thread: PRINTF_BUFR_SIZE in freebsd6
- Next by thread: How to "detach" a foreign driver from a device so my driver can attach?
- Index(es):
Relevant Pages
|
