Re: i386 trap code

2002-07-13 Thread Alfred Perlstein
* David Xu [EMAIL PROTECTED] [020712 19:38] wrote: when did the vm86_lock become spin lock ? I havn't seen changes in cvs, it is still a MTX_DEF. I had tried changing it to spin lock and got a panic. :( Did you also change the functions that access it to use mtx_*_spin? -- -Alfred

Re: i386 trap code

2002-07-13 Thread John Baldwin
On 13-Jul-2002 Alfred Perlstein wrote: * David Xu [EMAIL PROTECTED] [020712 19:38] wrote: when did the vm86_lock become spin lock ? I havn't seen changes in cvs, it is still a MTX_DEF. I had tried changing it to spin lock and got a panic. :( Did you also change the functions that

Re: i386 trap code

2002-07-12 Thread David Xu
--- 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

Re: i386 trap code

2002-07-08 Thread John Baldwin
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

Re: i386 trap code

2002-07-08 Thread David Xu
--- 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

Re: i386 trap code

2002-07-08 Thread John Baldwin
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

Re: i386 trap code

2002-07-07 Thread David Xu
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

Re: i386 trap code

2002-07-07 Thread Jonathan Lemon
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

Re: i386 trap code

2002-07-06 Thread Terry Lambert
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

Re: i386 trap code

2002-07-06 Thread David Xu
--- Jonathan Lemon [EMAIL PROTECTED] wrote: In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: 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?)

Re: i386 trap code

2002-07-06 Thread Bruce Evans
On Fri, 5 Jul 2002, Jake Burkholder wrote: Apparently, On Fri, Jul 05, 2002 at 05:43:26PM -0700, Julian Elischer said words to the effect of; Looking at i386/exception.s one sees: [...] Now: would it not make a lot of sense to put doreti immediatly after calltrap: in

Re: i386 trap code

2002-07-06 Thread David Schultz
Thus spake David Xu [EMAIL PROTECTED]: I don't know if FreeBSD can run DOS program, if it can, then one CPU running DOS program can confuse another CPU which is running BIOS code because of this global flags. my current patch does not remove vm86_lock, it is still there, my orginal

Re: i386 trap code

2002-07-06 Thread David Xu
--- David Schultz [EMAIL PROTECTED] wrote: Thus spake David Xu [EMAIL PROTECTED]: I don't know if FreeBSD can run DOS program, if it can, then one CPU running DOS program can confuse another CPU which is running BIOS code because of this global flags. my current patch does not

Re: i386 trap code

2002-07-06 Thread Jonathan Lemon
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

i386 trap code

2002-07-05 Thread Julian Elischer
Looking at i386/exception.s one sees: ### .globl alltraps .type alltraps,@function alltraps: pushal pushl %ds pushl %es pushl %fs alltraps_with_regs_pushed: mov $KDSEL,%ax mov %ax,%ds

Re: i386 trap code

2002-07-05 Thread Jake Burkholder
Apparently, On Fri, Jul 05, 2002 at 05:43:26PM -0700, Julian Elischer said words to the effect of; Looking at i386/exception.s one sees: [...] Now: would it not make a lot of sense to put doreti immediatly after calltrap: in the same file so that one could follow the

Re: i386 trap code

2002-07-05 Thread David Xu
- Original Message - From: Julian Elischer [EMAIL PROTECTED] To: Peter Wemm [EMAIL PROTECTED] Cc: FreeBSD current users [EMAIL PROTECTED] Sent: Saturday, July 06, 2002 8:43 AM Subject: i386 trap code Looking at i386/exception.s one sees

Re: i386 trap code

2002-07-05 Thread Jonathan Lemon
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: 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