On Aug 08, 1999 at 09:57:10AM -0700, Mike Smith wrote:
> > > > Fatal trap 9: general protection fault while in kernel mode
> > > > instruction pointer = 0x48:0x8034
> > > > stack pointer = 0x10:0xc0279e98
> > > > frame pointer = 0x10:0x67890000
> > > > code segment = base 0xc00f0000, limit 0xffff, type 0x1b
> > > > = DPL 0, pres 1, def32 1, gran 0
> > > > processor eflags = interrupt enabled, resume, IOPL = 0
> > >
> > > Why is IOPL zero? I've also noted that making a bios16 call also
> > > results in IOPL being zero (I have more that I want to take up with you
> > > on that at some stage, since it's got me stumped, but one thing at a
> > > time).
> >
> > The IOPL should be zero, in order to virtualize interrupts. If it's
> > more than zero, the BIOS code can turn off interrupts, which isn't
> > something we want to do.
>
> Ok. I'm presuming then that we have a tss in place that allows I/O
> operations? That was my major concern...
Nevermind, I was thinking of vm86 mode. In vm86 mode, the IOPL doesn't
have anything to do with I/O, and we use the I/O permission bitmaps.
There isn't an I/O bitmap for the kernel (only user processes), so the
kernel isn't able to make vm86 I/O calls at this point. This could be
fixed, but I haven't seen the need for it yet.
However, this is 16-bit protected mode, which (other than the addressing
size) is exactly the same as 32-bit kernel mode. Thus the IOPL doesn't
really matter, since all the bios selectors are set up with kernel privs
(in ring 0).
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
