In article 
<local.mail.freebsd-current/[EMAIL PROTECTED]> you 
>sorry for a bit OT, does anyone see this in_vm86call crazy global variable?
>it prevents two CPUs to trap into VM86 model :(

Um, unfortunately, this is by design.  Most (all?) BIOSen code are
single threaded, and the vm86 code shares the entire ISA hole, including
the read/write BIOS data area.  Allowing more than one CPU to execute
BIOS code at once is asking for trouble, since there is no way to know
what memory locations are being shared.

Now that vm86_lock serves the same function, we could check that lock
instead of of the global flag.

>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 :

I haven't looked at vm86 for a long time, but the original code worked
by preventing any ASTs from being taken until the BIOS returned.  It's
likely that this needs to be reworked for -current.

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

Reply via email to