> On Tue, 14 Jul 1998, Kendall Bennett wrote:
>
> > 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.
>
> theoretically it's possible to use 8K ioperm bitmap without bloating
> _every_ task in the system, but it's hard. Now we are talking 2.1,
> correct? If you look at the current implementation, we include a 128 byte
> IO bitmap in every task's TSS. The TSS is part of every task_struct,
> currently at the head of every kernel stack:
Actually I have tried compiled the 2.0.35 kernel sources with an 8Kb
I/O bitmap (I just grabbed the latest 2.1 sources so we will start
hacking on this), and it did not work. Specifically there were some
bugs in the ioperm() function in that the set_bitmap function it
calls takes 'short' parameters and is not able to set more than 32768
I/O ports at a time. I fixed that, but it still does not work. I
replaced the iopl(3) call in my code with ioperm(0,65536,1) and any
code that does I/O to high ports causes a seg fault. Also any I/O to
ports above 0x3FF cause a trap in the VM86 task and we fall back on
our emulation (which faults because I removed the iopl(3) call for
testing purposes).
Is there some other place in the kernel that knows about the size of
the I/O bitmap (I could not find any) thay might be tripping us up?
> obviously, we can not increase the bitmap to 8K because we have the stack
> there.
You have lost me on this one. Is there something that will be
preventing me from simply recompiling with IO_BITMAP = 2048 and
expecting it to work (well there must be, but I don't know what ;-)?
> _but_, the 'task->tss.bitmap' 16-bit pointer does not have to point to an
> unfragmented extension of the TSS. There might be a hole inbetween. So we
> might make the bitmap-pointer point to the next 8k boundary, which could
> contain a full 8K IO-permission bitmap.
>
> ---> 8K aligned address [ struct task_struct:
> ...
> struct thread_struct tss;
> ...
> short bitmap; ----------\
> ... |
> ... |
> ---> end of task_struct |
> [.... some unused memory ...] |
> |
> [ ... kernel stack, variable size 'a few K' usually ...] |
> [ ... possibly vm86 state ...] |
> ---> next 8K aligned address |
> [ ... FULL 8k IO-permission bitmap ... ] <---------------/
> ---> next 8K aligned address
>
> unfortunately this needs a 16K allocation when we create a vm86 task, (and
> we allocate a 8K bitmap only for vm86 tasks, which might be slightly
> unclean), which does in no way help our current fragmentation problems :(
I understand what you are trying to say, but I would not have the
foggiest clue how to implement it!
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