[PATCH] Do not trap access to timer and keyboard
ajax at nwnk.net
Fri Mar 19 11:29:55 PDT 2010
On Wed, 2010-03-17 at 23:26 +0100, Samuel Thibault wrote:
> Adam Jackson, le Wed 17 Mar 2010 17:44:34 -0400, a écrit :
> > On Sat, 2010-03-13 at 02:26 +0100, Samuel Thibault wrote:
> > > - ioperm(0x40,4,0); /* trap access to the timer chip */
> > > - ioperm(0x60,4,0); /* trap access to the keyboard controller */
> > I'm not sold on this. You really do not want to be bashing these ports
> > directly if the kernel also is.
> Sure. The issue is that some VESA BIOS do need it.
> > If this _is_ right, then it almost certainly needs to be done for all
> > platforms.
> Well, actually only Linux and Hurd used to do it. Since Linux also
> set iopl to 3 to be able to access to ports >= 0x400, the I/O bitmask
> set by ioperm() is just completely ignored, and the same two lines in
> the Linux code don't have any effect.
Ah, I get it. x86emu is dutifully emulating the I/O port cycle, but
since the kernel removed your permission to touch those ports, you
SIGILL. If you were using vm86 the same thing would happen; you'd trap
to the server to handle the I/O cycle, which would then proxy it on,
which would then SIGILL.
Well in that case, the ioperm() is definitely bogus on all platforms,
since all it can do is make us crash. But it indicates that the int10
wrapper needs to do a better job of emulating those ports, since the
kernel is definitely going to be using them.
Of course, Hurd doesn't have a kernel interface for PCI config space, so
you're already racing with the kernel all over the place.
(Gedankenexperiment: Kernel and X attempt a config space cycle at the
same time. Kernel writes to 0xCF8. X writes to 0xCF8. Kernel reads or
writes to 0xCFC. What garbage does the kernel get now?) So this is
clearly a race you can win most of the time, but still.
> > Do you have a link to a bug that this is solving?
A copy of the VBIOS would be useful here:
# dd if=/dev/mem of=/tmp/vbios bs=64k skip=12 count=1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the xorg-devel