From owner-freebsd-current Sat Jul 6 2: 7: 4 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 08A9637B400 for ; Sat, 6 Jul 2002 02:07:02 -0700 (PDT) Received: from web20906.mail.yahoo.com (web20906.mail.yahoo.com [216.136.226.228]) by mx1.FreeBSD.org (Postfix) with SMTP id B3C7743E31 for ; Sat, 6 Jul 2002 02:07:01 -0700 (PDT) (envelope-from bsddiy@yahoo.com) Message-ID: <20020706090701.37865.qmail@web20906.mail.yahoo.com> Received: from [218.108.156.1] by web20906.mail.yahoo.com via HTTP; Sat, 06 Jul 2002 02:07:01 PDT Date: Sat, 6 Jul 2002 02:07:01 -0700 (PDT) From: David Xu Subject: Re: i386 trap code To: Jonathan Lemon , current@freebsd.org In-Reply-To: <200207060557.g665vhm16951@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 --- Jonathan Lemon wrote: > In article > > you write: > >sorry for a bit OT, does anyone see this in_vm86call crazy global variable? > >it prevents two CPUs to trap into VM86 model :( > > Um, unfortunately, this is by design. Most (all?) BIOSen code are > single threaded, and the vm86 code shares the entire ISA hole, including > the read/write BIOS data area. Allowing more than one CPU to execute > BIOS code at once is asking for trouble, since there is no way to know > what memory locations are being shared. > > Now that vm86_lock serves the same function, we could check that lock > instead of of the global flag. > > > >I have also fixed the problem that VM86 call is preempted by interrupt > >threads and causes system crash. newest patch can always be gotten from : > >http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz > > I haven't looked at vm86 for a long time, but the original code worked > by preventing any ASTs from being taken until the BIOS returned. It's > likely that this needs to be reworked for -current. > -- > Jonathan I don't know if FreeBSD can run DOS program, if it can, then one CPU running DOS program can confuse another CPU which is running BIOS code because of this global flags. my current patch does not remove vm86_lock, it is still there, my orginal purpose is while CPU in VM86 mode, when hardware interrupt occurs, still allow interrupt thread to run. David Xu __________________________________________________ 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