Does anybody understand how icount TCG is supposed to arrange to respect timer deadlines?
https://bugs.launchpad.net/qemu/+bug/1754038 has a test case which shows that we don't get this right. At the moment what happens is: * when we're about to call tcg_cpu_exec(), we call prepare_icount_for_run(), which looks at the closest clock deadline to figure out how many insns to execute before dropping out, with a cap at INT32_MAX nanoseconds * however, if the guest reprograms the clock during the tcg_cpu_exec() run, we don't do anything to cause us to stop earlier * so we blithely continue on til that INT32_MAX cap, and then belatedly notice that we should have fired a timer interrupt In the test case this manifests as the first timer interrupt being very delayed, because the first tcg_cpu_exec() goes from "start of program" to INT32_MAX nanoseconds. Later interrupts happen OK, because the guest isn't reprogramming the timer interrupt, so the deadline picked at the start of each tcg_cpu_exec run is correct. What should we be doing to arrange to stop execution of the tcg_cpu_exec() earlier when the deadline moves closer? thanks -- PMM
