On 08-Jul-2002 David Xu wrote:
> --- John Baldwin <[EMAIL PROTECTED]> 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
>> > 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 <[EMAIL PROTECTED]> <>< 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
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message