Date: Sat, 9 Nov 2002 01:24:12 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Luoqi Chen" <lchen@briontech.com> Cc: <hackers@FreeBSD.ORG> Subject: Re: RE: Int 0x15 and VM86 question Message-ID: <200211090924.gA99OCEs006419@apollo.backplane.com> References: <AHEKICEOIHLOGINAFIINAEGFCAAA.lchen@briontech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I got it all figured out now. Boy, what a mess... and all because
BIOS INTn calls still use a 20+ year old cpu model. Basically
when the cpu goes into 8086 emulation it runs in ring 3 (user).
If the iopl is a higher priority, aka less then 3, certain
instructions including INTn instructions will trap via the IDT.
Real interrupts still operate as real interrupts via the IDT.
Our trap handler detects the INTn instruction and 'simulates' an 8086
interrupt frame by modifying the return frame and the 8086 stack.
That's how it works in a nutshell. The VME stuff is even weirder,
I'm not sure why we even bother with it.
What's funny is that we have all this code to write out a sequence
of 8086 instructions to actually run the originally requested INTn in
8086 mode, plus we have all this code to simulate the 8086 INTn when
they traps back to us. It would make a whole lot more sense to simply
build the 8086 INTn context in the first place and trap the IRET
instead of writing out a sequence of 8086 instructions to run. We'd
still need the trap handler since the BIOS is likely to make INTn calls
itself, but it would be a lot cleaner.
Again, thanks for your help Luoqi.
-Matt
Matthew Dillon
<dillon@backplane.com>
:...
:mode idt vector. Depending on your vme setting and interrupt redirection
:bitmap, it either triggers a general protection fault (vme clear and redir
:bit set), or directly jumps to vector at low memory as in real mode (vme
:set and redir bit clr). IIRC vme is available for P5 or later processors.
:So for you it most likely is the direct jump. The first page of physical
:memory (which contains the BIOS vectors) is not touched by the kernel,
:and is mapped at address 0 in the vm86 process space.
:
:Does this answer your question, Matt? It has been quite a while since
:I looked at the stuff, some of the descriptions might not be accurate.
:
:-lq
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211090924.gA99OCEs006419>