Going from virtual machine to real hardware

[trinopoty]

Hello everyone,
I was wondering, if my code runs fine in a virtual machine does it mean the code will run without any trouble on real hardware with similar configuration.
I currently test all my code in VmWare Workstation 7.1 , Virtual Box 4.1 and Bochs 2.4.6

[Kevin]

No, emulators usually use a simplified model of the hardware, which is designed to work well with a driver that works on real hardware. This means that emulators only really consider those parts of the state that they need for emulation, a big part of the hardware state may be ignored. If you only test on emulators, you might be taking shortcuts that won't work on real hardware.

And of course, emulators do have bugs.

[trinopoty]

I use Bochs for debugging purpose and only when the other two indicates a problem. I thought VmWare Workstation is almost equivalent to real hardware.

[rdos]

I run all my tests on real hardware. I have 5-6 different machines to test on. The only emulator that can run RDOS is virtual PC, but it lacks decent video support, so that means it is not useful for tests. It also emulates old hardware that few people use nowadays.

As for debugging, I no longer need emulators for debugging, but I have instead since long had built-in debug support that can handle most things I need to debug. When I did need emulators, they didn't seem to exist (late 80s, early 90s).

[Qeroq]

Hm, rdos, that sounds quite strange to me; what features are causing the problems with the other emulators and is it an erroneous implementation on the side of the vms or are you making use of some off-spec "glitches" you experienced with your test machines?

[rdos]

Hm, rdos, that sounds quite strange to me; what features are causing the problems with the other emulators and is it an erroneous implementation on the side of the vms or are you making use of some off-spec "glitches" you experienced with your test machines?

I think it is because most OSes initially are constructed with emulators as tools, and then when some function in the emulator doesn't work as intended, the OS adapts, not the emulator. The only exception to this rule is perhaps Windows and Linux, which "must" run on emulators. But that still leaves all the functions that Windows and Linux doesn't use as largely "untested".

As an example, there is a paging bug in Bochs, which I adapted to. There is also a PIT channel 2 emulation error in Bochs which I have not adapted to.

[Kevin]

I can't remember having knowingly adapted my code to emulator bugs, but I occasionally fixed some bugs in the emulator (qemu in my case) during OS development. You should probably report your bochs bugs to get them fixed, and ideally even provide a patch so that the maintainer doesn't have much work with fixing it - it usually takes less time to get fixed this way.

[rdos]

I can't remember having knowingly adapted my code to emulator bugs, but I occasionally fixed some bugs in the emulator (qemu in my case) during OS development. You should probably report your bochs bugs to get them fixed, and ideally even provide a patch so that the maintainer doesn't have much work with fixing it - it usually takes less time to get fixed this way.

I would have done this if I needed Bochs for OS-development, but I don't so I don't have time to fix patches for Bochs when I don't need it for development.

[shikhin]

Hi,

As an example, there is a paging bug in Bochs, which I adapted to.

Just curious, so, mind describing what paging bug in Bochs?

Regards,
Shikhin

[rdos]

I no longer remember the exact details, but it had to do with changing the page-tables in the pagefault handler, and Bochs not emulating TLB / physical page entries in memory correctly. The compensation I used was a TLB-flush in the page fault handler for a non-existent page. Without this, Bochs would under some special conditions (which I don't remember exactly) use an entry that a real CPU with a real TLB would not.

[Brendan]

Hi,

I no longer remember the exact details, but it had to do with changing the page-tables in the pagefault handler, and Bochs not emulating TLB / physical page entries in memory correctly. The compensation I used was a TLB-flush in the page fault handler for a non-existent page. Without this, Bochs would under some special conditions (which I don't remember exactly) use an entry that a real CPU with a real TLB would not.

That sounds like a bug in your code (e.g. failing to invalidate TLB entries when a page goes from "not present" to "present"), rather than a bug in Bochs.

Different CPUs handle this case differently. For Intel CPUs (as far as I know) the TLB never contains entries for "not present" pages (even though Intel have never said that a CPU won't or can't) so code does work if it fails to invalidate when a page goes from "not present" to "present". For some CPUs (Cyrix) the TLB can contain entries for "not present" pages so code that doesn't invalidate properly causes problems. Either way is "80x86 compatible"; and just because it works on Intel CPUs doesn't mean it is right (or that it won't fail on future Intel CPUs, or non-Intel CPUs, or various emulators).


Cheers,

Brendan

[rdos]

That sounds like a bug in your code (e.g. failing to invalidate TLB entries when a page goes from "not present" to "present"), rather than a bug in Bochs.

Different CPUs handle this case differently. For Intel CPUs (as far as I know) the TLB never contains entries for "not present" pages (even though Intel have never said that a CPU won't or can't) so code does work if it fails to invalidate when a page goes from "not present" to "present". For some CPUs (Cyrix) the TLB can contain entries for "not present" pages so code that doesn't invalidate properly causes problems. Either way is "80x86 compatible"; and just because it works on Intel CPUs doesn't mean it is right (or that it won't fail on future Intel CPUs, or non-Intel CPUs, or various emulators).

It was several years since I fixed this, so I don't remember the exact details. What I found in SVN-history was that I had added a TLB invalidate after handling a non-present page fault. I'm pretty sure that is the Bochs fix, and that it is not needed on any real hardware I'm aware of like Intel, AMD, Geode or other. It was more complex than just TLB invalidations. Maybe it was related to faults in the page-directory? I'm not sure.

[Combuster]

Author: rdos
Version: too old
Steps to reproduce: none given
Result: bug invalid and not worth anyone's time.


Beyond that, the TLB is known to store non-present pages or otherwise outdated privileges on real hardware so any such emulated behaviour could be considered correct.

[raghuk]

For Intel CPUs (as far as I know) the TLB never contains entries for "not present" pages (even though Intel have never said that a CPU won't or can't)

Intel has officially confirmed this. Latest Intel docs say:

Because the TLBs cache only valid translations, there can be a TLB entry for a page number only if the P flag is 1 and the reserved bits are 0 in each of the paging-structure entries used to translate that page number. In addition, the processor does not cache a translation for a page number unless the accessed flag is 1 in each of the paging-structure entries used during translation; before caching a translation, the
processor sets any of these accessed flags that is not already 1.

[trinopoty]

Guys, I think we are going a bit off tropic.