We are getting very close to having our SuperVGA Kit and MGL graphics
libraries running under Linux. One of the requirements to make this
work is the ability to call the real mode BIOS to set the display
mode and to find out information about available modes via the VESA
VBE/Core interfaces. We have been using Josh Vanderhoof's Linux Real
Mode Interface code to do this, and so far it is working very well.
However I do have a problem that affects some cards, and that is that
Linux only allows ioperm() to work on ports from 0-0x3FF and iopl(3)
does not affect the V86 task. What this means is that the v86()
system call returns with an exception when the V86 code issues an I/O
instruction for ports outside of the 0-0x3FF range, which we capture,
emulate from 32-bit ring 3 code and then return to the executing V86
task.
This works fine except for the fact that the I/O port virtualisation
is causing problems for cards that have timing sensitive code in
their real mode V86 BIOS (ATI 3DRage Pro is the card I am working on
right now). The virtualisation causes the execution times of the I/O
instructions to screw up the timing senstive code and the BIOS does
not function correctly.
In order to solve this I need to somehow enable full I/O access for
the I/O ports that the BIOS uses. Since there is no defined
menchanism to determine this, we basically need to globally enable
all I/O port access, at least for the duration of the calls to the
BIOS. Now from what I understand, there are three different
approaches that could be used to solve this problem:
1. We can modify the kernel such that it uses the full 8Kb of I/O
permission bitmaps for every process, such that we can then use
the ioperm() call to enable those ports outside of the 0x3FF
range. This is a solution that will work easily because ioperm()
works for the V86 task that is executed via the v86() system call.
This option is something that I know will work and will require a
kernel re-compile. However I dont specifically know how I would go
about changing the kernel sources to support this, so can someone
give me a heads up on how to do this so that I can at least verify
that I/O access is indeed the problem I need to solve?
2. We can somehow modify the kernel and the iopl() call such that it
also affects the V86 task executed via the v86() system call. This
would then allow full I/O for the V86 task without the need to
bloat the per-process I/O permissions bitmap. However I don't know
that this is even possible (can you assign an IOPL level for V86
code?).
If this is possible, can someone give me some pointers about what
in the kernel sources I would need to modify in order to make this
work?
3. We can modify the kernel such that the V86 task is given a
complete 8Kb I/O permissions bitmap, allow us to globally enable
I/O for that task. I don't know if this is easy or possible
without requiring that all other tasks also get an 8Kb I/O
permissions bitmap.
Once again if this is possible, can someone help me figure out how
to do it?
As far a final solution goes, I don't think Linus will want the
kernel to have to support an 8Kb I/O permission bitmap for every
task just so we can call the BIOS effectively. Hence I would like to
be able to use either solution 2 or 3 if possible. Solution 2 would
be ideal so long as it is possible within the x86 architecture (and
the kernel). If this is not possible then I think a mechanism to
allow solution 3 to work would be the best bet so that we only need
to burden the V86 support code with the 8Kb I/O permission bitmap.
NOTE: Whatever solution we come up with to solve this, it will make
the DOSEMU support for VBE graphics modes work a lot better that it
does right now (I get the same problem is I run our DOS utilities in
a DOSEMU DOS box). Hence I think it is in the best interest of the
Linux community to find a good solution for this...
Regards,
+--------------------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+--------------------------------------------------------------------------+
| Kendall Bennett | Email: KendallB@scitechsoft.com |
| Director of Engineering | Phone: (530) 894 8400 |
| SciTech Software, Inc. | Fax : (530) 894 9069 |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+--------------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html