> On Thu, 16 Jul 1998 16:36:31 -0800, Kendall Bennett said:
> > > /* The following hack allows the IO_BITMAP to be a nonstandard size */
>
> > Cool! I will definately try this out!!
>
> Given your next note I assume this worked.
Yep, it worked like a champ, thanks!
> > > 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
Ok, I will take a look at it.
> (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.
Sounds interesting. I am not sure I understand the need to put VBE
services into the kernel, rather than leaving them in user space and
simply relying on the v86() system call to handle the V86 portions of
the code. This is how we have done it in our code, and it works great
except for the necessity of the 8Kb I/O bitmap.
Does your kernel solution somehow avoid the need for an 8Kb I/O
bitmap for the V86 code?
> 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.
Ahh, so that is one way to get around it. I am not sure that I like
this solution since it duplicates the existing v86() system call
code. I would prefer to find a solution to reuse that code but
provide it with full I/O permissions (since that will also make
DOSEMU stuff work much better).
> 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...).
This wont work because the BIOS will be doing real mode specific
segment arithmetic and stuff that simply wont work in 16-bit
protected mode. In fact on the things that we designed into the
VBE/Core 3.0 spec was the support for a 16-bit protected mode entry
point, such that the BIOS code is built as 'bi-modal' so that it can
run in either environment (but there is a flag it can use to execute
mode specific code). Some vendors have already implemented this in
their BIOS such as NVidia in the Riva128 BIOS.
ATI also has the ability for their code to be called as 16-bit
protected mode via an internal entry point (however that is all ATI
specific).
> 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.
Yep, it does sound like it might get complicated. Does anyone know
the answer to this?
> 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.
Well I had a kernel running just fine that has IO_BITMAP_SIZE=2048,
but without the extra patch you sent me ioperm() did not work
properly in allowing the high I/O ports proper access, since
something was obviously stomping on the values again. Hence I dont
think the stack stuff had anything to do with it (otherwise my kernel
would have panic'ed on bootup I guess ;-).
> > 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.
Well I checked into this since there are now a lot of good sources of
information in Dr Dobb's and www.x86.org about EVM86 mode. However it
turns out that all this stuff is simply related to more efficient
handling of reflected interrupts and the virtual interrupt flag and
does nothing to solve the I/O port access problem. Oh well.
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