Date: Fri, 12 Jul 2002 22:21:35 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: current@FreeBSD.ORG, David Schultz <dschultz@uclink.Berkeley.EDU>, David Xu <bsddiy@yahoo.com> Subject: Re: i386 trap code Message-ID: <XFMail.20020708152746.jhb@FreeBSD.org> In-Reply-To: <20020707111727.A77366@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020708152746.jhb>