OSDev.org

I came up with this idea while in another thread, but it was kind of out of place.

Wouldn't it be useful if there was a way that you could test someone else's OS project on a real machine without any fear of it crashing and somehow destroying your data/hardware? I think it would be a good idea to write a very small piece of code that works as a simple VM for privileged instructions, and is itself run on the bare hardware, acting as a "gatekeeper" for ports. The real kernel would probably be run in ring 1, and all privileged calls would be trapped to the VM. It would be configured at compile/assemble time to either reject or accept certain actions, but would never emulate anything. A bit of self-modifying code could be used to handle all privileged instructions with one handler too .

There would be three main advantages of this over something like VMware or Bochs. First off, it is several orders of magnitude smaller and simpler, and would need no operating system support. Second, all hardware for the VM would be *real* hardware, so drivers for real devices could be written and tested. Plus, the processor is real as well, so things can be realistically tested on different machines - that's the whole reason for testing on real machines anyway. Third, it would run at almost completely native speeds, except for the privileged instructions, which would take a dozen or so extra clock cycles.

Additionally, it could also have a built in default IDT and GDT that would trap faults even before the kernel sets up its own handlers. This would be handy for debugging early stages of kernel development, both on real hardware and within a full virtual machine.

Does this seem like a useful and, more importantly, feasible idea?

NickJohnson wrote:I came up with this idea while in another thread, but it was kind of out of place.

Wouldn't it be useful if there was a way that you could test someone else's OS project on a real machine without any fear of it crashing and somehow destroying your data/hardware? I think it would be a good idea to write a very small piece of code that works as a simple VM for privileged instructions, and is itself run on the bare hardware, acting as a "gatekeeper" for ports. The real kernel would probably be run in ring 1, and all privileged calls would be trapped to the VM. It would be configured at compile/assemble time to either reject or accept certain actions, but would never emulate anything. A bit of self-modifying code could be used to handle all privileged instructions with one handler too .

There would be three main advantages of this over something like VMware or Bochs. First off, it is several orders of magnitude smaller and simpler, and would need no operating system support. Second, all hardware for the VM would be *real* hardware, so drivers for real devices could be written and tested. Plus, the processor is real as well, so things can be realistically tested on different machines - that's the whole reason for testing on real machines anyway. Third, it would run at almost completely native speeds, except for the privileged instructions, which would take a dozen or so extra clock cycles.

Additionally, it could also have a built in default IDT and GDT that would trap faults even before the kernel sets up its own handlers. This would be handy for debugging early stages of kernel development, both on real hardware and within a full virtual machine.

Does this seem like a useful and, more importantly, feasible idea?

This is just exactly what Vmware does (or did few years ago before hardware VT) - a technique called ring compression.
The problem is simple - amount of priviledged stuff OS does is so big that you end up with having complete JIT module into your VM, otherwise performance sucks.
There is some nice powerpoint presentation by Xen people which explained the problems of that approach.

P.S> Hardware VT solutions are especially have all the propertities as you explain.

Stanislav

I realize that's what VMware did/does, but no virtual machine I've encountered is able to use the real hardware - the real undocumented video cards, the real slow-seeking hard drives, the real buggy floppy drives. That's why I think it would be valuable for doing driver development. It would also be best to use segmentation and ring compression for this so people could run it on old hardware as well.

If you'd be able to use real hardware, you could have race conditions and such. Having a mechanism for mutual exclusion would make the system act weird and wouldn't be real-like for drivers either. If you're talking about only one OS running at a time, that's just bare metal anyway.

The point is that it needs no OS support - it is standalone on the bare hardware - and it only runs one OS. The difference between it and just bare metal is that you can make it block certain I/O ports, therefore protecting the test hardware from bad/malicious kernel code. My real question is if it would be useful enough to make a protective layer for test machines that I (or someone else) should try and write such a thing.