Diference between Bochs and quemu

[hgb]

Hi there, I have a function (traslated from c to asm), that havent tested on real hardware, but if I pass a 5 like argument, in quemu wait aprox 5 secs while in bochs is only a little delay... it work in PM and RM, dont know in wich two to "trust".

Code: Select all

%define CMOS1 0x70
%define CMOS2 0x71

delay_RTC:
%define secs bp+4
push bp
mov bp, sp
   push cx
   push bx
   mov cx, [secs]
   sub cx, 1
   jmp .check
   .again:
      invk read_CMOS_reg, 0
      mov bl, al
      .again2:
         invk read_CMOS_reg, 0
         cmp bl, al
         jz .again2
   sub cx, 1
   .check:
   jnz .again
   pop bx
   pop cx
pop bp
ret 2

[GLneo]

the good thing about bochs is that just about everything is adjustable, to set bochs timing to real time put in your setup file:

Code: Select all

time0: 1
pit: realtime=1

[hgb]

mmm, aparently here dosent work ok that??? Im using version 2.2.2 .

By the way, I have manually adjusted in the option console...

option 3 (modify) -> option 14 (other opts) -> option 4 (Clock parameters) ->

And I have put realtime (and the menu look like this)
2. sync=realtime
3. initial time=1

But when running is almost the same behaviour (no delay for 5 secs).

[Brendan]

Hi,

The timing for Bochs is meant to be deterministic, so that running the emulator a second time gives the exact same (virtual) timing as it did the first time. This is difficult to achieve as the host computer may be running other software at the same time. To be deterministic Bochs uses virtual time rather than real time, where virtual time has nothing to do with real time.

Being deterministic is important if you're trying to find a timing related bug (for e.g. an OS that crashes when eventA occurs before eventB, when the exact timing of both events may cause it to work correctly most of the time). It can also be useful for normal debugging - for e.g. if you know the OS crashes at T=12345678 then you could get Bochs to stop at T=12345670 just before the crash.

Since the original design other people have added different options in an attempt to make virtual time correspond to real time, and others have added other time related options.

AFAIK (and I'm no expert) all timing was orignally derived from the number of instructions executed. To "calibrate" this there's an "ips: ?" setting that determines how many instructions should be executed before Bochs thinks a second has passed. To set IPS correctly you're supposed to compile the kernel with "./configure --enable-show-ips", run the emulator, and read the measured IPS value from the log. Then you'd set the correct IPS value in "bochsrc.txt" and recompile without "--enable-show-ips".

The "pit: realtime=1" and the "time0:" options are obsolete for Bochs 2.2. They have been replaced with a "clock:" setting. For example (see the Bochs documentation for full details):

clock: sync=none, time0=utc
clock: sync=slowdown, time0=utc
clock: sync=realtime, time0=local

The problem is that it's impossible to be deterministic and have the highest performance while still keeping virtual time the same as real time. One of these three things needs to be sacrificed to get the remaining 2, which is where the 3 different "sync=" options come into it.

For "sync=none" Bochs is deterministic and runs at full performance, but virtual time doesn't correspond to real time. This has always been the default behaviour of Bochs. Even though virtual time doesn't correspond to real time it can be close enough for normal use when IPS is set correctly.

For "sync=slowdown" Bochs will wait if virtual time goes too fast. This reduces performance, but it is deterministic and if "IPS" is set low enough virtual time will correspond to real time.

For "sync=realtime" Bochs will run at full performance and virtual time will correspond to real time. In this case Bochs will not be deterministic.

In my experience, as long as IPS is set/calibrated correctly the other options don't matter too much....


Cheers,

Brendan

[hgb]

There is a way taht I can calculate the calibration or should I compile it?? some like velocity of processor / 2 ???? == calibrated IPS.

[Brendan]

Hi,

There is a way taht I can calculate the calibration or should I compile it?? some like velocity of processor / 2 ???? == calibrated IPS.

Not reliably - the speed of IPS depends on the instructions Bochs needs to emulate, and how the CPU is initialized. For example, Bochs can do a pile of "nop" instructions relatively fast, but SSE instructions would be relatively slow. For code in protected mode Bochs needs to do a pile of access checks that can be skipped in real mode (so for real mode code Bochs would use a faster IPS).

It also depends on which optimization settings are used to compile Bochs - for e.g. if you use the "fast strings instructions" optimization then things like "rep stosd" will work quicker than they otherwise would (resulting in a lower IPS, depending on how often the emulated code uses string instructions). Of course using Bochs to simulate SMP slows it down too.

And It depends on how fast your computer is, how well your compiler optimizes, how efficient the host OS is, how much other software your computer is trying to run in the background, etc.

As a very rough guide, my dual 1 GHz Pentium III server (running Gentoo without the OS doing much else) is around 3000000 IPS while Bochs is emulating mostly simple integer operations (no FPU, etc) in protected mode with a single emulated CPU. Unfortunately Bochs is single-threaded so the server's second CPU doesn't help much.


Cheers,

Brendan

[hgb]

Interesting, I have been testing diferent values and I have choice 7000000, before I have a number like 10000 but in that way, the timer was more fast... or something like that....

By the way, quemu is good for test the speed of your code, but not do work for test , that is like I feel???, but I feel this version of bochs more fast???

By the way, I have tried get some log things, how to read this???
interrupt(): vector = 16, INT = 1, EXT = 0 and for what aparently the timer is reset each time... (tought havent see the bochs page) there is reference for read this logs????

[Brendan]

Hi,

Interesting, I have been testing diferent values and I have choice 7000000, before I have a number like 10000 but in that way, the timer was more fast... or something like that....

Yes - with a higher value for IPS Bochs does more work for each "virtual second", which makes the virtual second longer in real time.

By the way, quemu is good for test the speed of your code, but not do work for test , that is like I feel???, but I feel this version of bochs more fast???

AFAIK QEMU skips some tests that are usually not needed, which makes it faster (but less likely to find bugs). I'm not sure if the latest version of Bochs is faster than previous versions or not - it supports more and does have less bugs though..

By the way, I have tried get some log things, how to read this???
interrupt(): vector = 16, INT = 1, EXT = 0 and for what aparently the timer is reset each time... (tought havent see the bochs page) there is reference for read this logs????

"interrupt(): vector = 16, INT = 1, EXT = 0" would mean the CPU is about to generate an interrupt 16. "INT = 1" means it was a software interupt, and "EXT = 0" means it wasn't an external interrupt (e.g. an IRQ). Somewhere in your code you're using "INT 0x10"...

In general the normal messages you get in the log are easy enough to figure out, but for the "DEBUG" messages you often need to dig through the Bochs source code - for e.g. the function "bx_pit_c::handle_timer()" starting at line 167 of "iodev/pit_wrap.cc", where it displays the message "pit: RESETting timer." when the PIT timer count reaches 0 and is reset to a new count (I think).

IMHO the "DEBUG" messages are intended for Bochs developers rather than Bochs users like me (but that doesn't stop me from using them)....


Cheers,

Brendan

[hgb]

I see, nice.

By the way, continuing with bochs . Here is the default config for log options that I have:

Code: Select all

Current log settings:
                 Debug      Info       Error       Panic       Pass
ID    Device     Action     Action     Action      Action      Action
----  ---------  ---------  ---------  ----------  ----------  ----------
  0.  [IO   ]     ignore     report     report      fatal      fatal
  1.  [KMAP ]     ignore     report     report      fatal      fatal
  2.  [CPU  ]     ignore     report     report      fatal      fatal
  3.  [APIC?]     ignore     report     report      fatal      fatal
  4.  [MEM0 ]     ignore     report     report      fatal      fatal
  5.  [VTIME]     ignore     report     report      fatal      fatal
  6.  [PIT  ]     ignore     report     report      fatal      fatal
  7.  [PIT81]     ignore     report     report      fatal      fatal
  8.  [IOAP ]     ignore     report     report      fatal      fatal
  9.  [STIME]     ignore     report     report      fatal      fatal
 10.  [DEV  ]     ignore     report     report      fatal      fatal
 25.  [SYS  ]     ignore     report     report      fatal      fatal
 26.  [CTRL ]     ignore     report     report      fatal      fatal

And here is What I supose they mean???

Code: Select all

ID    Device       My explanation
----  ---------    -----------------
  0.  [IO   ]      Generated when in, out are used, perhaps other thing activate it
  1.  [KMAP ]      ????
  2.  [CPU  ]      I see that this is reported like CPU0, in fact the important messages like triple faults and suchs things?
  3.  [APIC?]      The ? is a number (If Im not wrong) and is the APIC (I dont know much about this things)
  4.  [MEM0 ]      Memory... read, write???
  5.  [VTIME]      Dont know.
  6.  [PIT  ]      The PIT that is standar (but I don know much about it)
  7.  [PIT81]      Dont know the diference with the above.
  8.  [IOAP ]      ammm.... :S
  9.  [STIME]      ammm for second time :)
 10.  [DEV  ]      Perhaps the disks like floppy, hd, cdr and suchs...
 25.  [SYS  ]      ammm...
 26.  [CTRL ]      ammm...

And the suposed actions:

Code: Select all

Debug:   Used for debugging (the device).. like say Brendan .. perhaps for the developers?
Info:    The device whant say something or "clarify" or be more explicit in with respect other message, or the actions that are taked each time... ??.
Error:   The device has detected a error.
Panic:   Dont know way a Device will be scary! :D
Pass:    Pass in time... but havent reported?... like: uhh!!!, now I remember something that I must tell you time a go. ????

What to do for the anterior actions

Code: Select all

ignore: Dont do anything for the specific device action (dosent matter wich action is)
report: it report in console a specific message
ask: it ask for continue(ignore) terminate(fatal)...
fatal: it terminate completely Bochs.

Also in the config file if you specify a file for the log, then all the reactions to actions (messages) will be saved there, if not (put instead of name a "-"), they will be dumped to console.




OK, after clarify that, wich devices matter more, I supose CPU0??





Edit: I have watched that log options for each device are not saved to the config file... Then I cannot save the configuration for specific device???

[hgb]

;D hehe, I have finded a work around, perhaps you already know, but for edit log options for individual devices.

I attach a file that contain secuence of numbers, new lines and the specific configurations.

Then when you are in the first page of bochs configuration, you only need open the file "individuallog.txt" select all, copy and paste in the console, because the archive have the suficient new lines and deleted triling garbage, it will configure each device independly and will return ready to the first "page" of the configuration, for hit enter and start the simulation , for example:

Code: Select all

Current log settings:
                 Debug      Info       Error       Panic       Pass
ID    Device     Action     Action     Action      Action      Action
----  ---------  ---------  ---------  ----------  ----------  ----------
  0.  [IO   ]     ignore     ignore     report     ignore     ignore
  1.  [KMAP ]     ignore     ignore     ignore     ignore     ignore
  2.  [CPU  ]     ignore     ignore     ignore     ignore     ignore
  3.  [APIC?]     ignore     ignore     ignore     ignore     ignore
  4.  [MEM0 ]     ignore     ignore     ignore     ignore     ignore
  5.  [VTIME]     ignore     ignore     ignore     ignore     ignore
  6.  [PIT  ]      fatal     ignore      fatal      fatal     ignore
  7.  [PIT81]     ignore     ignore     ignore     ignore     ignore
  8.  [IOAP ]     ignore     ignore     ignore     ignore     ignore
  9.  [STIME]      fatal     ignore     ignore     ignore     ignore
 10.  [DEV  ]     ignore     ignore     report     ignore     ignore
 25.  [SYS  ]     ignore     ignore     ignore     ignore      fatal
 26.  [CTRL ]     ignore     ignore     report     ignore     ignore

And you can duplicate the configuration without configure each time that you run bochs .