David Xu wrote:
> >         testl   $PSL_VM,TF_EFLAGS(%esp) /* are we in vm86 mode? */
> >         jz      doreti_notvm86
> >         cmpl    $1,in_vm86call          /* are we in a vm86 call? */
> sorry for a bit OT, does anyone see this in_vm86call crazy global variable?
> it prevents two CPUs to trap into VM86 model :(
> if you have interest in fixing this problem,  please have a look at PR :

This is on purpose.  Most BIOS implementations are non-reentrant,
and if you allocate resources in the bus space to BIOS based I/O,
you end up contending for it without locks.  This is "crossing the
beams" bad... 8-).

> http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/38223
> I have also fixed the problem that VM86 call is preempted by interrupt
> threads and causes system crash. newest patch can always be gotten from :
> http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz

I saw the fix.  I like it, though it doesn't fix the handling
using an interrupt gate to take interrupts in VM86() mode (the
FreeBSD code doesn't do this at present, but it's a problem if
you run under VMWare, I think).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to