Page 1 of 1
Diference between Bochs and quemu
Posted: Wed Jun 01, 2005 1:22 pm
by 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
Re:Diference between Bochs and quemu
Posted: Wed Jun 01, 2005 1:51 pm
by 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:
Re:Diference between Bochs and quemu
Posted: Wed Jun 01, 2005 5:38 pm
by 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).
Re:Diference between Bochs and quemu
Posted: Wed Jun 01, 2005 10:36 pm
by 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
Re:Diference between Bochs and quemu
Posted: Thu Jun 02, 2005 7:25 am
by hgb
There is a way taht I can calculate the calibration or should I compile it?? some like velocity of processor / 2 ???? == calibrated IPS.
Re:Diference between Bochs and quemu
Posted: Thu Jun 02, 2005 10:18 am
by Brendan
Hi,
rea wrote: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
Re:Diference between Bochs and quemu
Posted: Thu Jun 02, 2005 11:09 pm
by 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????
Re:Diference between Bochs and quemu
Posted: Fri Jun 03, 2005 1:59 am
by Brendan
Hi,
rea wrote: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.
rea wrote: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..
rea wrote: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
Re:Diference between Bochs and quemu
Posted: Fri Jun 03, 2005 8:41 am
by 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???
Re:Diference between Bochs and quemu
Posted: Fri Jun 03, 2005 9:19 am
by 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
.