Date: Fri, 10 Jan 1997 12:08:53 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: gurney_j@resnet.uoregon.edu Cc: m230761@ingenieria.ingsala.unal.edu.co, jeand@myrias.com, emulation@freebsd.org Subject: Re: DOS Emulation (*sigh*) Message-ID: <199701100138.MAA29877@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.NEB.3.95.970109102338.7673E-100000@hydrogen.nike.efn.org> from John-Mark Gurney at "Jan 9, 97 10:40:54 am"
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney stands accused of saying: > > if I remeber correctly... the problem was that the patches weren't in a > CVS tree at the time it worked... also.. it was a userland hack to ring0 > (i.e. user process with complete access to EVERY thing) that was allowing > it to work... and this isn't a good "production" idea... You don't remember very well. 8) - It's been in my CVS tree at home (available for sup) since day 1. The kernel patches were revolting and never worked properly. - DOSCMD uses vm86 mode, and most certainly _never_ ran the user process in ring0. The kernel handles emulation of some of the simpler priveledged instructions (cli/sti), and initially all raw I/O is passed off to the user-space emulation module. Sometime further down the track, there are plans to use a seperate tss for an emulated process, and allow selective direct-mode hardware access. > from a message by Michael Smith (quoted with out his permission): > (If anyone does want to help; change the size of the sigcontext struct, > recompile your kernel, and then come back with an enumerated list of > other things that need to be changed to stop it from crashing. We > could _really_ use some help here.) > > so that should explaine what needs to be done... assumeing this is still > the problem... ttyl.. It is the current stumbling block on the path to the correct solution. The patches currently available have a basic problem in that they exit to vm86 mode via a private return, which is Bad and Evil because it means that the scheduler doesn't run, and thus a vm86 process which doesn't trap to the userland emulation code can never be scheduled, and appears to lock the system up. You get this with DOS programs that spin on the BIOS tick counter; normally the userland emulation would have SIGALRM delivered on a regular basis for maintaining time-related illusions. However, with the vm86 process spin-looping, the clock interrupt occurs, the SIGALRM is posted, and the interrupt handler returns, but because it goes out through the backdoor to vm86 mode, the scheduler doesn't run, and so the emulation module can't receive its signal. Likewise on the clock interrupt when the vm86 process' quantum expires. - Fixing this requires some reworking of the generic exit-to-userland code. - Reworking the exit-to-userland code requires adding some extra members to the sigcontext structure. - Adding extra members to the sigcontext structure causes subtle kernel confusion and instability. And that's where we're at now. Part of the problem is that Sean has a Real Job, and is thus rather busy. I do too, and on top of that I don't understand the relevant internals well enough. There's lots of much easier grunt work required, but without a solution to this showstopper, I'm not inclined to waste my time organising it. 8( > John-Mark -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701100138.MAA29877>