have you met any pitfall with qemu?

[miaowei]

I am writing a driver for RTL8139 recently, so i have to test it under QEMU( bochs only supports e1000 and ne2000 ).
For this reason, i want to use QEMU as my daily develop environment in future days.
since so many people insist on bochs, i think there must be some shortages with QEMU. Who can tell me a little?

-------------------------
yestoday my kernel cracked when tested with QEMU for the first time, the bug is finally located here:

Code: Select all

int ll_rw_block2(...){
                ...
                ll_rw_block(dev_id, rw, curr ...);
	         kp_sleep(0, 0);
                ....
          }

ll_rw_block() is a non-blocked function for block device read/write. I use a wrapper function 'll_rw_block2" to make a blocked version and i implement it in a easy way: just put the process who just issued a block I/O request into sleep mode.

this function runs ok on bochs and real machine, but failed with QEMU. The reason is that I/O on QEMU is incredible fast, we received a disk IRQ before kp_sleep() !!

I fixed this bug using "cli" instruction to wrap the two lines ablove into a critical area ...

Anyway, this is a little pitfall i found on QEMU. can you write your experience here?

[Combuster]

since so many people insist on bochs

Bochs is more accurate, more configurable, throws better error messages at you, and doesn't need any other software to do debugging. In comparison, QEMU sacrifices a lot - including doing things a real processor won't do - for speed. That makes Bochs the best recommendation for anybody starting with OS development in general, and a good thing to enforce if QEMU is actually hampering in their progress: "Have you run it under Bochs and read the error messages?".

One of my peevees with QEMU is that it actively tells you it supports something (VME) when it does not, and that CLI;HLT; stops video updates, making it appear as if crashes occurred earlier than they actually did.

[miaowei]

Bochs is more accurate, more configurable, throws better error messages at you, and doesn't need any other software to do debugging. I

i am a bochs user, but i have not used its internall debugger for a long time. My kernel grows larger by days, debugging with gdb-sub saves me a lot of time.

BTW, do you know why bochs not support RTL8139 since it's such a classic network card. It seems that bochs support it in early version, i guess by some google information.

[Combuster]

RTL8139 since it's such a classic network card.

Ne2k's are a much older standard and support tends to be better - particulary in terms of DOS. I would assume the devs considered it not useful to add a device that didn't actually broaden support feature-wise - which would be covered by the e1000 as it adds gigabit support. The only RTL8139 reference in relation to bochs is that someone had a physical RTL8139 that he wanted bochs to drive.

Besides, QEMU has many other NICs to choose from, some of which look obscure. I also don't have any actual RTL8139s so I can only demonstrate a significant standard deviation on the subject (I have a single e1000 though ).