Date: Sun, 7 Jul 2002 11:17:27 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: David Xu <bsddiy@yahoo.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, David Schultz <dschultz@uclink.Berkeley.EDU>, current@FreeBSD.ORG Subject: Re: i386 trap code Message-ID: <20020707111727.A77366@prism.flugsvamp.com> In-Reply-To: <20020707065950.88612.qmail@web20901.mail.yahoo.com> References: <20020706110658.A36596@prism.flugsvamp.com> <20020707065950.88612.qmail@web20901.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020707111727.A77366>