Larger IO bitmap?

Hello.

I was trying to add some VESA support to dosemu and found that on my Radeon7500 card it requires an access to the ports from range 0x9800-0x98ff. As ioperm() doesn't allow to open such a ports, I've got a very slow graphics.
What happens is this:
IO attempt->GPF->return_to_dosemu-> decode insn->change uid->change IOPL-> do IO->change IOPL->change uid-> back_to_DOS_execution.
You may guess how slow it is, but if I say that it is as slow as the simple screen redraw takes up to a minute, that may still be a surprise:)

My question is: why do we still have a 128-bit IO bitmap? Is it possible to have the full 8K IO bitmap per process under Linux? And if yes, then why not yet? (Note: I am using the latest 2.4 kernels and I don't know if there is something changed in 2.5 about that problem. If something is changed, then sorry for wasting your time).

I think that could be an advantage also for X. I think currently X works around the problem by keeping IOPL==3 all the run, but that can't work for dosemu.

I've found several discussions on that topic, but they all ended unconclusively (too difficult, too expensive, useless etc). But as the last discussion I've found was dated 1998, I think it is time to reiterate:)

Can anyone please suggest what must be done in order to enlarge the thing? The obvious way of increasing IO_BITMAP_SIZE constant doesn't do the trick.

Guess you (and I) need to read the code.
Now that we have per-CPU TSS segments,
8K per CPU would not be a big problem, but
you'll probably need to copy 8K bitmap
into TSS whenever dosemu task starts executing
on that CPU ('normal' tasks won't need large
io bitmap). That's slow but better that what you see now :)

Another question is where to keep it.
You probably need a pointer in task struct
and dynamically allocate bitmap for dosemu-like beasts... --
vda

Hi,

Increasing the IO bitmap size has huge effects on your Task State Segment size. It sure is possible to increase that size, but be aware that this means you are using megabytes for your TSS's only !

Of course, with current memory sizes, some might say "why bother", but IMHO it is still a very good reason not to do it. The Embedded guys will sure agree with me.

Running iopl(3) isn't that bad, as long as your code knows what it is doing... Ioperm is only needed for virtual 8086 mode (aka DOS emulation mode) and is nice for buggy code. (If you don't trust your own programming skills and think you might pass wrong parameters to outb() )

You need root privileges for both iopl and ioperm requests, so that is no argument eighter. The fact your software runs setuid root automatically means you trust the software.

With this in mind, dosemu is the only reason why the bitmap should be extended. (virtual 86 mode uses the bitmap to emulate io access when needed). In my humble opinion, dosemu is not important enough to make TSS's huge bloated things by default.

The advantage for XFree would be that it needs to call ioperm() a thousand times instead of calling iopl() once. That sure is an advantage in my eyes...

Well... it might be an option in the kernel on x86 systems: [ ] bloat kernel memory usage with huge TSS's, but I really thing this should not be the default way to go.

Jos

We have per-CPU TSS, not per task
--
vda

Keep in mind that a task's io bitmap is now lazily allocated, so by default no memory will be allocated for it. A similar enhancement for large vs small io bitmaps could be made by allowing the task io bitmap to be a variable size.

-ben