OSDev.org

I believe bochs, is the worst x86 emulator ever seen on the earth (except my own). It doesn't correctly emulate the PIT, doesn't crash when needed (so you can believe it's all ok), and now it don't load correctly the GRUB GDT.

VMWare is so much better. The only thing it needs is a debugger. Does anyone know how to debug a vmware virtual machine?

Actually, bochs is the *best* x86 emulator out there.

qemu: Not an emulator, it's a DBT (dynamic binary translator)
vmware, xen, kvm: Not emulators, they're hypervisors.
not certain about VPC, haven't used it, don't know what technologies it uses.

It *does* correctly emulate the PIT. If you set it to realtime mode, it'll emulate it in realtime. Otherwise, it'll just fire interrupts when it can (to make your program run as fast as possible).

It *does* crash. If you want to alleviate the "zero memory" problem (all memory is zeroed making bad pointers harder to detect), just memset all of physical memory to a sentinel value, like 0xdeadbaba.

And it *does* correctly load the grub gdt.

I have never really had an issue with it.

I use both BOCHS and VPC and they both work fine.

And does this really belong in this forum? maybe general programming/ramblings?

I am sometimes ambivalent with bochs. It was the first emulator on which multitasking worked for me. But now my code has matured and when something is wrong its the first emulator on which things doesnt run well anymore. I also remarked its the slowest emulator. I don't know what microsoft want to do of VPC, but I know it's an emulator, not an hypervisor (yet?). VPC is from connectix who originally made it for the macintosh, and it was really fast I found.

Bochs works fine with BIOS functions, ever they are implemented in its own way. But yes, it is the worst emulator that can use for hardware system I/O programming. For example, the bochs Video BIOS code will never work at real hardware. I recommend you to use Virtual PC. It is far more better and most likely use windows drivers for I/O programming. It is as close to the real hardware as it is possible for level 3 - user level program.

Every Virtual PC has some flaws. Some won't load my disk image with the size mod 512 != 0. Others won't disable user input on mouse and keyboard. Some trigger one keyboard IRQ after initializing for no reason.

I have workarounds in my kernel just for virtual machines. :/

It's "probably" not flaws, but designed features. They are made to make the client operating systems run in a strange environment to make bugs surface, no?

You should look at all of the features Bochs has before posting that you hate it.

If something is failing, have Bochs output debug, warning, and error information to the log file. This will help you determine where the problem happened, and where to start looking.

ARGH! OMFG people RTFM before posting!

VPC is *not* an emulator! As I (thought) earlier on, it is a virtualization suite when run on windows*.

So Bochs is the only emulator of the x86 architecture in common use. Everything else uses different techniques to speedup, and are NOT emulators!

Seriously, get your fricking facts right before ranting - of course it's slower than others - it's an emulator!

* http://en.wikipedia.org/wiki/Virtual_PC

JamesM wrote:ARGH! OMFG people RTFM before posting!

VPC is *not* an emulator! As I (thought) earlier on, it is a virtualization suite when run on windows*.

So Bochs is the only emulator of the x86 architecture in common use. Everything else uses different techniques to speedup, and are NOT emulators!

Seriously, get your fricking facts right before ranting - of course it's slower than others - it's an emulator!

* http://en.wikipedia.org/wiki/Virtual_PC

Sorry to interrupt, but I don't think you know what an emulator is. VMware and Virtual PC are definetely emulators.

This is an emulator: "A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system."

Whether it uses certain techniques to speed it up is totally irrellevant.

And in any case you should get your facts right before ranting. Because VMware Workstation/VMware Player (which is what you would use for testing your OS) does NOT act as a hypervisor (as you claim). It runs as any normal user program.

Whether a simulator uses CPU emulation of virtualisation technology *does* make a big difference. Bochs emulates each individual instruction in software whereas VPC and the like use virtualisation technology (if run on an x86 or x86-64 cpu - the Mac version emulates x86 IIRC).

Trying to compare Virtual Machines like VPC and VMWare with emulators like Bochs is like trying to compare apples and oranges - they are two different things. This difference is why Bochs debugger is even possible in the first place - bochs is actually storing the machine state in software the whole time it is running.

Cheers,
Adam

This is an emulator: "A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system."

Correct. Use of virtualization technologies mean that the "emulator" is actually not "emulating" - it runs target code natively on the processor. Implicit in the above definition is a postphrase "And does not require the subject system". Virtualization does, emulation doesn't.

Whether it uses certain techniques to speed it up is totally irrellevant.

Unfortunately it is relevant, because it changes what target machine you can run a subject OS on. On bochs you can run x64 code on an x86 box, on vmware you can't as it doesn't *emulate* the processor.

Because VMware Workstation/VMware Player (which is what you would use for testing your OS) does NOT act as a hypervisor (as you claim). It runs as any normal user program.

It *does* use paravirtualised calls and it *does* set up a virtual machine. For want of a better word, it is a hypervisor.

This difference is why Bochs debugger is even possible in the first place - bochs is actually storing the machine state in software the whole time it is running.

Exactly. Bochs stores the subject machine state and executes using a virtual processor (written in C), qemu/vmware/kvm store the subject machine state *in the target processor and use the target processor to run instructions*.

And in any case you should get your facts right before ranting.

You have provided no evidence against my points. Just to end this post, I'll add a little background about what I do. I work as a placement student for Transitive Ltd, who provide cross-platform virtualisation technology (for example running x86 programs on a PPC processor). I deal with virtualisation every hour of every working day. I code and debug a translating emulator.

EDIT: from wikipedia:

Emulation refers to the ability of a program or device to imitate another program or device.

Note *imitate*. Virtualisation is by no means imitation.

As I know, Virtual PC tries to emulate as possible the machine it's running on.

I've discovered why the GDT doesn't works.
When you execute "CLI; HLT", bochs loads a new GDTR with base = 0 and limit = 0xFFFF. I've just changed the two instructions with JMP $ and now it works.

Also if you set realtime mode, the pit runs 10000 times faster

It *doesn't* crash. Try not to update ESP, just after GRUB. When the first CALL occours, on vmware you will experience a wonderful stack fault. On bochs, it works like it's all ok...

But there isn't any method to debug VMWare virtual machine?

EDIT:

Wikipedia wrote: VMware Workstation is a virtual machine software suite
Microsoft Virtual PC is a virtualization suite
Bochs is a portable x86 and AMD64 PC emulator
QEMU is a processor emulator that relies on dynamic binary translation

The Virtual machine article on wikipedia lists 3 techniques to create virtual machines. Two of that are emulation.

AlfaOmega08 wrote:As I know, Virtual PC tries to emulate as possible the machine it's running on.

Read the wiki article I liked to. It emulates on PPC, dynamically translates on x86.

I've discovered why the GDT doesn't works.
When you execute "CLI; HLT", bochs loads a new GDTR with base = 0 and limit = 0xFFFF. I've just changed the two instructions with JMP $ and now it works.

Also if you set realtime mode, the pit runs 10000 times faster

There is an option to make it work properly. Combuster has mentioned it before. It could be 'slowdown', but I thought it was 'realtime'.

It *doesn't* crash. Try not to update ESP, just after GRUB. When the first CALL occours, on vmware you will experience a wonderful stack fault. On bochs, it works like it's all ok...

That's because it *is* all OK. My kernel doesn't change the ESP tht grub gives it until it enables paging, and it works on qemu, bochs, vmware and 2 real boxen.

But there isn't any method to debug VMWare virtual machine?

NO! Because it doesn't emulate! VMWare uses the *target* processor to execute instructions. Bochs (and any other *emulator*) *emulates* the processor, so enabling single stepping properly.

EDIT:

Wikipedia wrote: VMware Workstation is a virtual machine software suite
Microsoft Virtual PC is a virtualization suite
Bochs is a portable x86 and AMD64 PC emulator
QEMU is a processor emulator that relies on dynamic binary translation

The Virtual machine article on wikipedia lists 3 techniques to create virtual machines. Two of that are emulation.[/quote]

OK, notice the use of "virtual machine" and "virtualization" in the first two names. QEMU can emulate OR be a DBT - it emulates on PPC and is a DBT on x86. (DBT != pure emulator)

Just because the word "emulation" in the title does not mean the technique uses a (processor) emulator. Notice the first title: "Emulation of the underlying raw hardware (native execution)". The only thing you're emulating there is the hardware. The processor still executes code natively. The second one, "Emulation of a non-native system", describes a "proper" emulator.

Emulation originally (and when used correctly) refers to the interfaces of two different things. That's the meaning of the word. Feel free to redefine it.

(I get the feeling that someone thinks a program (VMware) isn't different from a hardware device (a PC).)