Date: Sat, 8 Nov 1997 02:14:51 -0800 From: Jonathan Mini <mini@d198-232.uoregon.edu> To: Mike Smith <mike@smith.net.au> Cc: hackers@FreeBSD.ORG Subject: Re: x86 gods; advice? Suggestions? Message-ID: <19971108021451.30385@micron.mini.net> In-Reply-To: <199711080954.UAA00629@word.smith.net.au>; from Mike Smith on Sat, Nov 08, 1997 at 08:24:16PM %2B1030 References: <19971108014051.33398@micron.mini.net> <199711080954.UAA00629@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith <mike@smith.net.au> stands accused of saying: > > > > Well. Te only thing I can think of is to set up a task gate that will > > > > 'jump' you into a 32bit protected mode TSS, preferably the one where you > > > > started. (I'm assuming the kernel's) > > > > > > This was suggested by another respondent. I'd be very interested in > > > knowing how I could arrange such a thing, either overloading the > > > existing syscall callgate or making another for temporary use (I have > > > another free descriptor that I can hijack for the purpose). > > > > I don't know, I've never done it myself, personally. :) > > Ah. A handwave response. 8) I'll look at it tomorrow; it was > suggested that I buy a book - obviously a suggestion from someone that > doesn't live in this book-desert. I have a intel i386 architecture paper that is something like 300 pages long that's in ASCII format that I found somewhere along the line. It is very indepth, but I have personally never used it. (I own most of intel's specs in paper form) > > Ok, it is as I thought. Personally, I am a fan of the kernel keeping around > > a few contexts that it rarely uses. Basically, IMHO, it would be best if once > > the bootblocks got ahold of the system, they created three contexts : > > - a 32-bit 'we are the kernel now' context, > > - a 16-bit protected-mode 'let's play with the BIOS' context, and > > - a 16-bit vm86 'let's pretend we are a Microsoft OS' context. > > Too complicated, and inadequate. There is a separate 32-bit context > needed for the APM BIOS as well, and we are out of descriptors already. > The vm86 support handles this differently by creating a kernel process > at a later stage. *blinks* ok. I expected that shot down. > > The idea is that the various contexts would be able to be used to 'pitch in' > > when needed. For example, the boot process woudl change from hopping back and > > forth from protected mode to real mode into : > > > > - hop into protected mode, create a vm86 task which handle > > loading the kernel. (map the vm86 1M+ range to where you want the > > kernel to go, or do a 1:1 map of all physical memory, and then set > > the vm86's descriptor limit to 4G or so. Do all the loading from > > vm86 mode. much easier code to look at) > > Unfortunately, we have no tools for writing realmode code. I was > perhaps somewhat misleading regarding running the bootstrap in real > mode; please look at the code for an understanding of the issues. I have looked at FreeBSD's boot loading code in detail. As to writing realmode code, I feel your pain. Currently I am suffering from the same problem myself. The closest I have come is Bruce's bcc package, which is *ahem* an entertaining set of utilities. The C compiler has been more annoying that frustrating. > > - hop into the kernel, from the vm86 task. The kernel would be in > > a situation where it is in a ring 0 32bit TSS with a vm86 TSS which > > has mappings to do some basic BIOS calls for it, possibly even some > > complex ones. > > This isn't making a lot of sense to me. Are you implying that one > could be in 32-bit PM and vm86 mode at the same time? No. I am saying that the kernel has on it's hands two prepped and functional TSS's. One which describes a vm86 environment suitable for making BIOS calls, and another which is the 32bit protected mode TSS that the kernel is used to having. It looks like my message came out a little garbled. :( Thats what I get for trying to argue^H^H^H^H^Hdiscuss simulation physics with a friend while compsing a message about operating systems. (all I want for christmas is a multi-tasking mind. A premptively multi-tasking mind...) > > This means that there would be basically three parts to the kernel, a > > main kernel which is as the kernel is now, and two stubs which reside in > > vm86 and 16bit protected tss's. These stubs would be able to handle > > various simple actions, such as running a bit of code and then exiting the > > world via a call gate. (the effect would be similar to setting up a > > timeout. Set the timeout, go out to lunch, and then get a function called > > when the action is done) > > This is how the vm86 code works now. It's not usable for your > projected scenario however as the timeout code doesn't happen until > too late. Woops. I wasn't planning on using the timeout code at all. I was merely commiting a pilot error. I thought I had deleted all the para's pertaining to that misguided response. Doh. > > kernel, but the advantages would be _very_ nice. Unfortunatly, it would require > > a multi-section kernel, and a compiler which groks 16bit code. > > This latter is a crucial issue. Ding. I know. It is so bad that I am planning on writing a 16bit compiler to fill my needs. Unfortunatly, this is not a C compiler, so it probably won't help you any. > > > You've been able to run vm86 stuff in userland for ages; what is it that > > > you are missing? Unless someone can identify any serious security > > > holes in the implementation, vm86 support will stop being optional (at > > > least for the APM case, I hope). > > > > A way which would allow the protected mode code to request services of > > the vm86 code rather than visa versa. Currently, the only method I have > > created is for the task to do a vfork, and the child turns itself into a > > vm86 process with a monitor. > > What's the difference? Your execution passes between vm86 mode and > 32-bit PM; which direction information passes is entirely a semantic > issue. It is not the way the information passes, which the way that the process's control thread passes. Currently, it goes : pmode : (setup) -> vm86 (run run run) (fault) -> pmode (handle fault) <- (return) (run run run) I need : pmode : (setup) -> vm86 (perform subserviant task) <- (fault) (run run run) > > mike > > -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971108021451.30385>