On 12/05/2015 21:41, Peter Maydell wrote: >> > It's any instruction that can cause an icount read, typically through >> > QEMU_CLOCK_VIRTUAL or cpu_get_ticks(). > Also anything that can cause a CPU interrupt, since tcg_handle_interrupt() > will call cpu_abort() if the CPU gets an interrupt while it's not > in a 'can do IO' state. > > Anything else? > > [How are -icount and multi-threaded TCG going to interact? Do we > just say "you get one or the other but not both" ?]
For -icount and SMP, yes. I even posted a patch to that end once. You can get -icount and multi-threaded TCG (which for UP is simply TCG with execution out of the BQL) together I think. For example you could handle cpu->icount_decr.u16.low == 0 like cpu->halted, hanging the CPU thread until QEMU_CLOCK_VIRTUAL timers have been processed. The I/O thread would have to kick the CPU after processing QEMU_CLOCK_VIRTUAL timers---not hard to do. In fact, I suspect cpu->halted should become a kind of bitmap, and "wait for interrupt" should be just one bit in there. Any operation that requires synchronization with other VCPUs should use cpu->halted so that VCPUs can still run foreign code with run_on_vcpu. This was the plan I outlined to Frederic and Mark for flushing TLB remotely, at least. Paolo
