have you met any pitfall with qemu?
Posted: Sat Jun 11, 2016 4:03 pm
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:
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?
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);
....
}
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?