Date: Sat, 6 Jul 2002 23:59:50 -0700 (PDT) From: David Xu <bsddiy@yahoo.com> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: David Schultz <dschultz@uclink.Berkeley.EDU>, Jonathan Lemon <jlemon@flugsvamp.com>, current@FreeBSD.ORG Subject: Re: i386 trap code Message-ID: <20020707065950.88612.qmail@web20901.mail.yahoo.com> In-Reply-To: <20020706110658.A36596@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
David Xu
--- Jonathan Lemon <jlemon@flugsvamp.com> wrote:
> On Sat, Jul 06, 2002 at 05:15:26AM -0700, David Xu wrote:
> >
> > I don't know how DOS emulating program works, but if it let DOS
> > program run in VM86 mode, the in_vm86call global flag can prevent
> > one CPU to run VM86 BIOS call and another CPU run DOS VM86 code,
> > because it can not distinct which CPU the kernel is calling BIOS
> > and which CPU is running VM86 DOS code, under SMP this is a problem.
> > for exapmle, vesa module running on first CPU is calling VM86 BIOS,
> > and second CPU is running DOS program, the DOS program maybe simply
> > executes a privilege instruction to trigger trap, and the CPU
> > will see itself calling VM86 BIOS, but it shouldn't.
>
> The virtual vm86 mode that doscmd(1) uses is different than the
> vm86 bios calls (or bios16, or bios32) which allows direct execution
> of BIOS code. They do not have much in common. doscmd() does not
> directly execute any of the BIOS code; it provides its own BIOS
> emulator.
>
> The scenario you postulate above cannot exist.
> --
> Jonathan
__________________________________________________
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020707065950.88612.qmail>