Thanks for the reply.
> > We are trying to run guest SMP code with qemu icount mode, but based on my
> > current understanding I don’t think we can do that, because with icount
> > enabled, the multi cpus will be simulated in round-robin way(tcg kick vcpu
> > timer, or current cpu exit in order to handle interrupt or the ending of
> > the current execution translationblock) with the single vCPU thread, so
> > qemu is not running guest code in parallel as real hardware does, if guest
> > code has the assumption cores run in parallel it will cause unexpected
> > behavior.
>
> Timing of the emulated CPUs will always vary from that of real hardware to
> some extent.
I understand that, but at least we can get the deterministic result on load
heavily PC for emulated single core system if we can adjust the shift value to
the level of hardware frequency. And it will not work if icount qemu need
communicate with other real hardware, for example via TCP protocol.
> In general you can't expect QEMU's simulation to be accurate to the level
> that it will correctly run guest code that's looking carefully at the level
> of parallelism between multiple cores (whether using -icount or not.)
Not sure without icount(maybe it will be accurate if only QEMU is running on a
powerful PC), but I can understand it's not accurate with icount enabled, the
reason is as you mentioned below, there is the possibility that we have to spin
to wait another core, so the icount timer will be not accurate.
>
> SMP mode with icount (ie without MTTCG) will run all vCPUs on one thread, but
> since we always round-robin between them well-behaved guest code will make
> forward progress and will not notice any major differences between this and
> real parallel execution. (Sometimes it might spin a little more if it has a
> busy-loop waiting for another core, but only until the round-robin kicks in
> and runs the other core.)
Yes, agree with "well-behaved guest code will make forward progress",
please correct me if anything wrong.
BR
