From owner-freebsd-current Sat Jul 6 23:59:53 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C634237B401 for ; Sat, 6 Jul 2002 23:59:50 -0700 (PDT) Received: from web20901.mail.yahoo.com (web20901.mail.yahoo.com [216.136.226.223]) by mx1.FreeBSD.org (Postfix) with SMTP id 8E4CE43E3B for ; Sat, 6 Jul 2002 23:59:50 -0700 (PDT) (envelope-from bsddiy@yahoo.com) Message-ID: <20020707065950.88612.qmail@web20901.mail.yahoo.com> Received: from [218.108.144.153] by web20901.mail.yahoo.com via HTTP; Sat, 06 Jul 2002 23:59:50 PDT Date: Sat, 6 Jul 2002 23:59:50 -0700 (PDT) From: David Xu Subject: Re: i386 trap code To: Jonathan Lemon Cc: David Schultz , Jonathan Lemon , current@FreeBSD.ORG In-Reply-To: <20020706110658.A36596@prism.flugsvamp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jonthan, I just use DOS program as an example, for any program, if it wants to go into VM86 mode, it is very easy, just calls i386_vm86() to initailize its VM86 pcb extension, setups some memory area, then call sigreturn() to turn into VM86 mode. I think global in_vm86call flags is a bug under SMP, it creates a race condition. suppose this scenario: CPU A is running a simple VM86 code program. CPU B is running vm86_intcall() by some kernel driver (vesa module ?) CPU B set in_vm86call = 1 CPU A gets a fault trap. CPU A runs trap(), and find that in_vm86call is set and handles the trap as it is running vm86_intcall(), but it is not true and make a mess. David Xu --- Jonathan Lemon wrote: > On Sat, Jul 06, 2002 at 05:15:26AM -0700, David Xu wrote: > > > > I don't know how DOS emulating program works, but if it let DOS > > program run in VM86 mode, the in_vm86call global flag can prevent > > one CPU to run VM86 BIOS call and another CPU run DOS VM86 code, > > because it can not distinct which CPU the kernel is calling BIOS > > and which CPU is running VM86 DOS code, under SMP this is a problem. > > for exapmle, vesa module running on first CPU is calling VM86 BIOS, > > and second CPU is running DOS program, the DOS program maybe simply > > executes a privilege instruction to trigger trap, and the CPU > > will see itself calling VM86 BIOS, but it shouldn't. > > The virtual vm86 mode that doscmd(1) uses is different than the > vm86 bios calls (or bios16, or bios32) which allows direct execution > of BIOS code. They do not have much in common. doscmd() does not > directly execute any of the BIOS code; it provides its own BIOS > emulator. > > The scenario you postulate above cannot exist. > -- > Jonathan __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message