From owner-freebsd-hackers Sat Nov 9 1:24:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3457037B401 for ; Sat, 9 Nov 2002 01:24:14 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D77AD43E9E for ; Sat, 9 Nov 2002 01:24:13 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.5) with ESMTP id gA99OCFC006420; Sat, 9 Nov 2002 01:24:12 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.5/Submit) id gA99OCEs006419; Sat, 9 Nov 2002 01:24:12 -0800 (PST) (envelope-from dillon) Date: Sat, 9 Nov 2002 01:24:12 -0800 (PST) From: Matthew Dillon Message-Id: <200211090924.gA99OCEs006419@apollo.backplane.com> To: "Luoqi Chen" Cc: Subject: Re: RE: Int 0x15 and VM86 question References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 :... :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