OSDev.org

I am trying to wrap my head around this whole vm86 thing. Everything else im working through and learning more and more I have a console os that boots in protected mode can read pci devices do typical things working on usb has multitasking (sord of) but for the life of me I cannot grasp vm86.

Can someone please explain to me in the simplest like a pseudo vm86.

Heres what I have in my head
I have to compile the functions I want to do separately
link them to a certain spot
load that function into the lower memory
I guess before all that I make a general protection fault that triggers this
then my os should go and do int whatever and return the results

I am totally lost so if that doesnt make any sense at all please ignore it.

Thank You

jeff8j wrote:I am trying to wrap my head around this whole vm86 thing.

Let's start simple: do you know what vm86 is for? Do you understand the concept of real mode vs. protected mode?


JAL

Have you tried looking for vm86 in the wiki? There's the Virtual_8086_Mode page and the Virtual_Monitor describing vm86 mode, have you read these?

if you need a practical example, have a look at PrettyOS vm86 code used for vesa graphics:
http://prettyos.svn.sourceforge.net/vie ... iew=markup
http://prettyos.svn.sourceforge.net/vie ... iew=markup ("vm86-monitor")
http://prettyos.svn.sourceforge.net/vie ... iew=markup (vm86 examples)

Three things to know about v86,

1. It doesn't work in long mode.
2. Don't write any disk drivers in it, Win 95 did this, the system often crashes on improper timings
3. The only useful thing that *REQUIRES* v86 is switching to VESA legacy modes, otherwise, you'd have to write a neew driver for every computer you test on, and OEM product specifications are rarely as pretty as this wiki.

Cheers

From kernel's point of view vm86 is just a userspace code, mapped somewhere in 1st MiB of address space, running with one extra bit set in EFLAGS register.

From code's, running in vm86 mode, point of view it's essentially the same as real mode. So it must be 16-bit, do real mode segmentation and things like that.

The fun starts when that realmode code tries to do some nasty things, like disabling interrupts, accessing I/O ports, etc. If it was "real" real mode it would not be a problem, it would have full control. However, instructions like that is not allowed when running in ring 3, trying to execute them causes GPF.

Now, to accomplish our task (change video mode, for example) from within GPF handler we need to find out what exactly it was trying to do, emulate it (like reading I/O port) or at least pretend we did (like disabling interrupts) and then return from GPF handler to next instruction. For code running in vm86 it will look the same as if it that instruction was executed directly.

That's what vm86 mode and vm86 monitor is. How you do it in your OS is totally up to you.

Primis wrote:2. Don't write any disk drivers in it, Win 95 did this, the system often crashes on improper timings

This is often said; but untrue.

Well, same problem here. There are a lot of things I can grasp about vm86, but there are a few problems I can't get my head around. Maybe I am expecting to much of this mode, so it that's the case, don't be be blunt and tell me please!

First of all; I'd like to mention that my Operating System (codename HailOs - what's in a name :s) is becoming more mature. That is, I am currently in the stage of implementing the vfs part and when this is implemented, I want to develop a good virtual address space manager. You'd probably say, well, that is a long way to go! Yeah, I know, but I like to do my research and I am always thinking of what I could add to my kernel to make it more appealing. So, the quest for VESA support was born. Since then I'm trying to find lots and lots of information on the vm86 mode. Allthough the concept is not that hard there are some things that need more explanation.

1. Imagine I have a task that starts at 4 MB boundary. Is it possible to have a portion in that task that executes realmode code by doing a system call? I understand I have to map this portion to the first MB of userspace, but then? Just setting the VM bit, do the proper tss handling and go?
2. How about the BIOS code. I assume the BIOS is can only be called if I was smart enough to save the realmode IDT, BIOS code and data area at startup, am I correct?

I would also appreciate it when I could get some reading material, no code please, but more schematic things like abstract flowcharts or an in depth article about vm86 mode. I am googleing my head of lately, without getting my answers! Could be that my search phrases are totally wrong ofcourse.

B.t.w.1. The concept of a vm86 monitor is totally clear for me and I am aware of its importance. Enough information to find about this part.
B.t.w.2 It is not my intention to takeover this thread. Should anyone think of me doing so, I would like to ask the moderator to make a nice seperate thread. Thank you!

Greetz,
Hailstorm

hailstorm wrote:First of all; I'd like to mention that my Operating System (codename HailOs - what's in a name :s) is becoming more mature.

Congrats.

1. Imagine I have a task that starts at 4 MB boundary. Is it possible to have a portion in that task that executes realmode code by doing a system call?

No, a "task" (or "process") runs either in v8086 mode or not. It cannot have a "portion" that executes realmode. Well, theoretically you could, but you don't want that: you want a normal, protected mode task to call a service or the like that does something for you, and the OS makes sure it is handled by the v8086 task.

2. How about the BIOS code. I assume the BIOS can only be called if I was smart enough to save the realmode IDT, BIOS code and data area at startup, am I correct?

Yes, you are. If you have only a single v8086 task (in case you only use it for doing BIOS calls, as opposed to say run a real mode DOS emulator or the like), it suffices to not mess with the lower 1MB of memory (which you shouldn't anyway, given the fact that it houses system tables, ROM and video memory), and make sure that (in case you use paging) the v8086 has the first 1MB identity mapped (although you may want to remap the video memory address range, to prevent the BIOS mess with that). Alternatively, you could of course make a copy to some other location, and map that.

I would also appreciate it when I could get some reading material, no code please, but more schematic things like abstract flowcharts or an in depth article about vm86 mode.

There's really not much to it: a v8086 task is like any other task, except that it runs in real mode, and thus has access to only 1MB of memory, uses 16 bit code etc.


JAL

jal wrote:

1. Imagine I have a task that starts at 4 MB boundary. Is it possible to have a portion in that task that executes realmode code by doing a system call?

No, a "task" (or "process") runs either in v8086 mode or not. It cannot have a "portion" that executes realmode. Well, theoretically you could, but you don't want that: you want a normal, protected mode task to call a service or the like that does something for you, and the OS makes sure it is handled by the v8086 task.

That depends entirely on what you're doing; for example, I would say x86emu would be right to have the v8086 mode data mapped at the bottom of its address space.

Owen wrote:That depends entirely on what you're doing; for example, I would say x86emu would be right to have the v8086 mode data mapped at the bottom of its address space.

I'm not sure what you mean by "v8086 mode data", nor what part of my post you are referring to. What I was stating is that a normal task does not switch to v8086 mode, but that a task is either a v8086 task or not. x86emu is an emulator, and does not switch to v8086 mode (nor is running in it).


JAL

jal wrote:

Owen wrote:That depends entirely on what you're doing; for example, I would say x86emu would be right to have the v8086 mode data mapped at the bottom of its address space.

I'm not sure what you mean by "v8086 mode data", nor what part of my post you are referring to. What I was stating is that a normal task does not switch to v8086 mode, but that a task is either a v8086 task or not. x86emu is an emulator, and does not switch to v8086 mode (nor is running in it).


JAL

Sorry, my mistake: I meant to say DOSEMU. And by "v8086 mode data" - I mean the emulated real mode address space.

Thank you guys for your input!

All I want to achieve with the vm86 mode is running BIOS code to get vesa to work. So I have been thinking. What if I inject the following code somewhere in the 1 MB area: The next step would be creating a systemcall or something similar that executes that interrupt by jumping to this code. The systemcall is responsible for setting up the tss for vm86 work and blocking the calling task. The calling task should deliver a structure with all general and segment registers. I know this is a very static solution, but it could work, right?

I'd like to see your responses...


Greetz,
Hailstorm

It's a lot easier to directly jump to the int 10h entry point (which you can read from the IVT), I think, so you don't have to inject any code at all.
(That's the way I do it)

Aha... And by checking the sp register you know the bios has finished its job (process-technically speaking)?