> 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:
---> 8K aligned address [ struct task_struct:
...
struct thread_struct tss;
...
short bitmap; -------\
... |
int io_bitmap[32]; <--/
...
---> end of task_struct
[.... some unused memory ...]
[ ... kernel stack, variable size 'a few K' usually ...]
[ ... possibly vm86 state ...]
---> next 8K aligned address
obviously, we can not increase the bitmap to 8K because we have the stack
there.
_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 :(
[note that with 'virtual stacks' it's easy to map another 8k of memory to
the proper virtual address, as the IO-permission bitmap is not in physical
memory but in virtual memory too.]
-- mingo
-
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