Il 22/07/2014 11:58, Sebastian Tanase ha scritto: > > -timers_state.cpu_clock_offset contains the offset between the real and > virtual clocks. > However, when using the value of the virtual clock > (qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL)), > qemu_icount_bias already includes this offset because, on ARM, > qemu_clock_warp (which > then calls icount_warp_rt) is called for the first time in tcg_exec_all, > making > qemu_icount_bias take the value of qemu_clock_get_ns(QEMU_CLOCK_REALTIME)
Does this means that QEMU_CLOCK_VIRTUAL counts up from qemu_clock_get_ns(QEMU_CLOCK_REALTIME) rather than 0? This would be a bug, and it would be good to fix it (by initializing vm_clock_warp_start to -1). > A solution to not compute the initial offset in qemu_icount_bias would be to > initialize > vm_clock_warp_start to -1. The result will be that qemu_icount_bias will > start counting when > the vcpu goes from active to inactive. At that time, vm_clock_warp_start will > already store the realtime clock > value and a timer on the real clock will be set to expire at clock + > deadline, making qemu_icount_bias increment > by deadline. That would be correct. > A consequence of initializing vm_clock_warp_start to -1 is also > the fact that we'll skip the first check for a virtual expired timer. As I > mentioned above, in ARM case, > it's not dangerous because there are no timers active the first time we > perform this check. However, this > is just a potential scenario and I cannot guarantee that on other target > architectures there won't be > an expired timer pending the first time we check. Like a timer that expired in the past? That would be caught in tcg_cpu_exec, when it initializes the decrementer to qemu_clock_deadline_ns_all(QEMU_CLOCK_VIRTUAL). > So, do you think it is worth taking this solution into account or it will > cause more harm than good? Yes, even more so. If we add workarounds to complicated code, it will become even more complicated. Paolo
