Date: Mon, 01 Sep 1997 12:09:21 +0930 From: Mike Smith <mike@smith.net.au> To: Jonathan Lemon <jlemon@americantv.com> Cc: =?iso-8859-1?Q?S=F8ren_Schmidt?= <sos@sos.freebsd.dk>, j_mini@efn.org, karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Message-ID: <199709010239.MAA00384@word.smith.net.au> In-Reply-To: Your message of "Tue, 12 Aug 1997 19:50:34 EST." <19970812195034.31150@right.PCS>
next in thread | previous in thread | raw e-mail | index | archive | help
(replying to an old message) > How would a vm86() interface be used? I don't think that just passing in > the i386 registers and an interrupt number to call would be enough; I think > that some of the INT calls want to pass data back and forth via low-memory > areas. In most cases, I see this interface being used by other kernel services to interact with BIOS functionality that's not available otherwise. Off the top of my head, the big consumers are likely to be : - Video control; access to the full set of VESA functionality - Resource management (especially the ECSD parameter space) > If that is the case, then the address space has to exist before and after > the call; probably the easiest way would be for the calling process to create > the address space and then pass it to the vm86 thread. Otherwise, the thread > could just attach to kernel area around 'atdevbase' I would, I guess, like to be able to say : - create vm86 context foo with memory size X, default layout, etc. - populate specific components of X - invoke <some functionality> in vm86 context foo - access X - destroy vm86 context foo At the bare minimum, the context should comprise the address space the vm86 thread has access to, the register state, I/O permissions, etc. It should be possible to copy code into the address space, or to request a set of "canned" operations. Perhaps pseudocode speaks this better : foo = vm86_create_context(64 * 1024, VM86_NOIOPERM, ...); VM86_INIT(foo); VM86_REG(foo, cx, 0x35); VM86_INTR(foo, 0x10, 0x55, 0x01); VM86_TERMINATE(foo); vm86_run_context(foo, ...); ie. create a context, initialise it for code insertion, insert code to set %cx to 0x35, insert code to call INT 0x10 major function 0x55 minor function 0x01, insert code to terminate the context, and then run the code in it. It might be desirable to supply some form of time limit in the run_context function to trap runaway invocations; that's probably fluff though. Being able to run it in parallel, and query it for status rather than blocking until it completes would be _very_ useful, as I'm sure you can imagine 8) > My current thinking (for the kernel) is: > > - create a 'vm86daemon', which maps in the lower physical 1M into > it's address space. Hmm. With the idea above, you would map the memory region belonging to the context at the bottom of the address space, and the ISA hole suitably, and leave most of the rest unmapped. I don't think too many callers will need an entire 1M mapped. > - submit requests to this thread, which puts the caller to sleep > until the request completes. I would be inclined to try to support more than one vm86 thread at once, with the possibility of asynch execution and notification (or even just blatant status polling). > Am I on the right track here, or am I totally off base? Sounds pretty groovy to me! mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709010239.MAA00384>