On 13 May 2015 at 09:42, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > 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.
I don't see why -icount and SMP need to be mutually exclusive. If we're round-robining between the SMP CPUs then they should all stay deterministic, I would have thought? > 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. Multithreaded TCG for a UP guest isn't very interesting though... -- PMM