> Cool! I will definately try this out!!
Given your next note I assume this worked.
> > I have attempted to allow the bitmap to be extended just for the V86 task
> > but I don't know whether it works as I haven't tested it since my video
> > card just uses the normal VGA I/O ports.
> We if you can show me a patch that does this, I can easily try it out
> on my end.
It is messy. :-) My VBE code at
http://www.comlab/oucl/users/ian.collier/vbe-0.1.tar.gz
(which is out of date and I wish I had time to work on the thing) is an
attempt to put the VBE support in the kernel. So far it only supports
VBE 2.0 implementations which don't contain nested INT calls (other than
INT 0x1a PCI stuff), but that will change in time. The only succesful
test reports have come from NeoMagic laptops. Of course, Red Hat has now
released a free (binary only) accelerated X server for NeoMagic so the
VBE driver is somewhat redundant, but if it can be improved to the point
of working on almost all hardware then it will be useful for supporting
new chipsets which come out before a "real" X server is written for them.
My VBE driver is running on 2.0.33 and 2.1.99 (I said it was out of date)
but only the 2.0.33 version has so far made it into the released version.
My next task is to attempt to make it emulate /dev/fb so as to get
software compatibility; after that perhaps it can be merged with the
fbcon driver.
Anyway, I digress. I honestly don't know whether it is possible to use
the kernel's existing VM86 support within another kernel driver, so I've
put another self-contained VM86 monitor into my driver. In order to enter
VM86 mode it needs to perform a task switch, so it steals an empty task
slot and uses that. Linux doesn't actually know about this "stolen" task
so it can have any size of bitmap I want. However, since Linux doesn't
know about it, Linux must not regain control while the task is running.
For that reason I also steal the IDT and disable interrupts. Yuck.
So far no one has offered me an easier way to do it (though one person
did suggest I should run it in protected mode in a 16-bit code segment -
doesn't sound to me like that would work too well...).
The problem I see with allowing the user-mode VM86 task to have a different
sized bitmap from other tasks is that the bitmap is in the middle of the
thread_struct and so all references to, e.g., tss -> tr depend on the
bitmap having a fixed size. Not having the Intel docs in front of me
at the moment I can't remember whether that is enforced by the processor
but I suspect that it is. All the stuff after the IO bitmap is purely
for Linux's benefit and not used by the processor. Now fortunately if
you can fix that then that's basically all there is to be fixed, but it
seems like a biggie.
I suppose one hack way to do it would be to put a pointer to tss->tr in
tss->esp1 (since that's not used for anything currently) and always
dereference via that, but it's messy. Incidentally I don't know what
all that was earlier about the stack since the stack is allocated
separately from the TSS and a pointer to it is stored in tss->esp0.
> Actually this brings up another issue. I recall reading in Dr Dobb's
> (I think) about the undocumented Pentium Enhanced V86 mode. One of
> the features of this if I remember correctly is that you can enable
> IOPL priveledges for V86 tasks rather than having to use a full 8Kb
> I/O bitmap.
It wouldn't surprise me if it were. Unfortunately, EVM86 mode is documented
in the Infamous Appendix H, which means that the Intel docs say "See
Appendix H for more information" but actually there is no Appendix H -
it's just a pointer telling you to apply to Intel for the documentation,
and presumably you have to sign NDA and such things before they will give
it to you.
Besides, that will only work on Intel Pentiums and I guess you want to
support 486 too, not to mention other manufacturers who may or may not
have an EVM86 mode.
imc
-
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