From owner-freebsd-current Mon Jul 8 17:47: 8 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 BE90737B406 for ; Mon, 8 Jul 2002 17:46:59 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0564943E52 for ; Mon, 8 Jul 2002 17:46:59 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13953 invoked from network); 9 Jul 2002 00:46:54 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Jul 2002 00:46:54 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g690kff06510; Mon, 8 Jul 2002 20:46:41 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020708233758.1620.qmail@web20905.mail.yahoo.com> Date: Mon, 08 Jul 2002 20:46:52 -0400 (EDT) From: John Baldwin To: David Xu Subject: Re: i386 trap code Cc: David Schultz , current@FreeBSD.ORG, Jonathan Lemon 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 On 08-Jul-2002 David Xu wrote: > > --- 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/ > > No, vm86_lock is not a spin lock, unless you change it now. > I saw a line in vm86.c: > mtx_init(&vm86_lock, "vm86 lock", NULL, MTX_DEF); Oof, bad memory on my part. A per-thread flag would probably be best, although using a per-PCB flag can work fine as well. Esp. since the PCB is MD and the flag would need to be MD. > fixing in_vm86call is not diffcult, problem is old code stores some parameters > in vm86 static pcb, so if the thread is preempted, when it switches back > again, if it gets parameters from the pcb, these parameters is already modified > > by cpu switch routine, old code assume it will never be preempted until BIOS > returns, this is true under RELENG_4, but obviously it is not true in CURRENT > source. Ok. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message