From owner-freebsd-current Fri Jul 12 19:38:48 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 7465B37B400 for ; Fri, 12 Jul 2002 19:38:45 -0700 (PDT) Received: from web20909.mail.yahoo.com (web20909.mail.yahoo.com [216.136.226.231]) by mx1.FreeBSD.org (Postfix) with SMTP id 2BF8E43E4A for ; Fri, 12 Jul 2002 19:38:44 -0700 (PDT) (envelope-from bsddiy@yahoo.com) Message-ID: <20020713023843.25720.qmail@web20909.mail.yahoo.com> Received: from [218.108.144.208] by web20909.mail.yahoo.com via HTTP; Fri, 12 Jul 2002 19:38:43 PDT Date: Fri, 12 Jul 2002 19:38:43 -0700 (PDT) From: David Xu Subject: Re: i386 trap code To: John Baldwin , Jonathan Lemon Cc: current@FreeBSD.ORG, David Schultz , David Xu In-Reply-To: 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 --- John Baldwin wrote: > > On 07-Jul-2002 Jonathan Lemon wrote: > > On Sat, Jul 06, 2002 at 11:59:50PM -0700, David Xu wrote: > >> 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. > > > > Yes, as I mentioned earlier, the way the original vm86 bioscall worked > > was to prevent an AST until the BIOS was done. This relied on the giant > > lock for correctness, since we only allowed one CPU into the kernel at > > once. There probably needs to be some work done for -current in this area. > > Since vm86_lock is a spin lock, you could possibly make in_vm86call per-cpu > or you could just check the lock instead of the variable to fix this. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ when did the vm86_lock become spin lock ? I havn't seen changes in cvs, it is still a MTX_DEF. I had tried changing it to spin lock and got a panic. :( David Xu __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message